-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Render name on place=neighbourhood polygons #4090
Comments
This is a duplicate of #103 |
How so? That was similar to the other issue in that it wasnt specific to neighbourhoods and inovolved larger areas with less definable boundaries like place=sattelement. Place=neighbourhood was only brought up a few times in it and known responded to anyone. In no does an issue about different tags where this one in only mentioned twice make this a duplicate of that one. Anymore then it would make every issue about icons a duplicate of the icon rendering issue or every issue about something to do with waterways a duplicate of a closed issue about bays. Or can we not have new issues about specific tags anymore just because similar ones where rejected or there's meta issues about semi-related ones? |
#103 also requests rendering on place=* settlement polygons, including place=neighborhood in addition to =quarter, =suburb, =village, =hamlet, =town, =city. And the linked PR addressed all of these. If we only render place=neighborhood lables on areas, but not other parts of settlements like place=quarter and place=suburb, this will be confusing to mappers and lead to requests to render the others, and that will lead to request to render place=town, place=village etc (since the distinction between a town and a suburb is vague). Two PRs about this were rejected: #2816 (as mentioned above) and also #2939 (which would only render settlement place nodes on areas if there is no node with the same tags inside). Comments in the first PR=:
See these comments in the second PR:
I believe most of these concerns apply equally to place=neighborhood as to place=village or place=town. Also see the discussion in the previous issue #103 for more. I don't think there is consensus to render this features when mapped as an area. It is normal to map boundary=administrative areas which might be the same as the neighborhood, and we do render these. Unfortunately in the USA the sub-city admin levels are poorly developed, so this solution does not work as well, but because of this, the names and areas of neighborhoods are undefined in many American towns and cities, making their areas non-verifiable. |
I checked the current use of place=neighbourhood in several regions: Out of 14 regions, only the 2 States in the USA, plus the country of Uruguay, had a significant number of areas mapped with place=neighbourhood. But even there, nodes are more common, and most of the areas are landuse=residential areas or sometimes administrative boundaries. In most places I checked, I found that only nodes were used. |
Because names on areas aren't rendered and names on nodes are. So there's no incentive to map them as areas. It says on the Wiki that they can be rendered that and its an improved tag with 40,000 uses as lines. So I dont see what the problem is. Especially since your recommending boundary=administrative be used instead. Which has the same issues but is still rendered. You should support what the community wants and approves instead of picking and choosing. Or just dont render anything that has the problem. Maybe you could at least compromise by making name rendering on polygons dependent on being a relation with nodes like it is with admin boundaries. I dont think anyone would have a problem with that and then it wouldn't be favoring one scheme over another. Btw, two things to add to that, the Wiki doesn't say not to map them as polygons or anything about unclear boundaries being a stopper to anything. It says it's perfectly fine to map them that way in cases where they have unclear boundaries because some are not administrative entities and inherently wouldn't. So your going against the consensus and recommending bad tagging suggesting using boundary=administrative instead when a lot of them aren't administrative and the Wiki doesn't require them to be. Second, every other map style, including OsmAnd and Mapbox renders places as areas. Including place=neighbourhood. So maybe it's just a personal bias by the few people who are against it. Even if it's not though, I've heard repeatedly on issues about adding new icons etc that you aren't going to because there isn't support in other things that use OSM. There's no reason it shouldn't work the other way around. If literally every other place supports something the style should to, just as much as the not if they don't. Otherwise, the standard is extremely one sided. |
Note as mentioned in #2816 (comment) many polygons with place=neighbourhood tag also have a landuse or an administrative boundary tag. At the moment of the 52k features >29k have a landuse tag and nearly 10k have an administrative boundary tag. Emphatic 👍 on not re-iterating the discussion from #103. |
No supprise there. Its already pretty clear what your opinion on this type of thing is. Would it at least be possible to get rid of the border around landuse=residential when its co-tagged with place tags since mapping them that way would involve "nesting landuse" and sometimes places dont have clear boundaries (the Wiki doesnt require them to)? It would be wrong to render a border arbitary for something and it just looks wierd having a random border inside a landuse area. It might be confused for a fence or something. |
That would be a separate issue
What do you mean? Each landuse=residential area can be mapped as a separate closed way or multipolygon to represent the area. The area would represent the actual residential area, which might be surrounded by a fence or wall, or just streets + other features on some sides. Looking at Shasta County, it looks like there are already many "subdivisions", "housing developments" and apartment complexes mapped as landuse=residential areas with the name of the housing area. This looks fine. There is also the older tag place=suburb for slightly larger sections of a town or city, bigger than a neighborhood, and even place=quarter for big cities which need 3 levels of subdivisions. |
Btw, my thing above is why I think this is a issue specific place=neighbourhood and that it should be considered separately from other places, because place=village or similar tags aren't being wrongly tagged as landuse=residential to make the name render and people aren't recommending it be tagged that way against the recommendation of the Wiki article for landuse=residential like is being done in this case. |
@Adamant36 I understand your reasoning. I can see advantages and disadvantages for including the name. If the label was on the map, it's handy to have so people know the different neighborhoods. However, it would look a little cleaner if the label wasn't on the map (especially if there are a lot of overlapping neighborhoods and other subdivisions of a town). I wouldn't draw a grey box and border around it the same way as landuse=residential which is ok because the issue is related to rendering names on the map.
I wonder if it would be a fair compromise to render neighborhood tags like boundary=administrative tags, but use a different color (like blue instead of purple?) and show the borders of each neighborhood.
From what you're saying, the tricky thing about having a neighborhood have a border like an administrative area is it looks like a "border" that might not exist for neighborhoods. But there is usually a well defined border for neighborhoods with areas, according to the wiki. The current process on the wiki (under How to Map > Node or Area?) has you draw an area and add another center node for the neighborhood. I think this is very convoluted, and I could argue that adding another tag to somewhere near the center to look good is "mapping for the renderer". But the name is already included if we tag the center node according to the wiki, so making areas render with just the name wouldn't change very much. |
It also goes against the "One feature, one OSM element" rule IMO. Plus, it's ridiculous that if you search for a location you get two results that way and they often have different tags. Like sometimes the node is tagged as a hamlet but the area is tagged as a city. Or the node will include Wikipedia tags etc but the area won't. It unnecessarily turns the whole thing into a crap shot, and makes it so people either get bad information or non at all. Same goes for admin boundaries. There was a hamlet in my local area that it three years and multiple notes to get the name to render on because no one could figure out how to get the relation between the node and area to work properly. Even though everything was otherwise tagged properly on both of them. Which is ridiculous and anti-user. If a place is tagged with the name, it should either display or not, but there shouldn't be some extra esoteric step (that most regularly editors don't know how to use) involved so it displays on the map. |
Currently place=neighbourhood polygons don't have name rendering unless they are also tagged with landuse=residential. Which seems like a workaround and bad tagging because it involves tagging landuse areas inside other landuse areas if you want neighbourhood names to render. Since there can be multiple neighbourhoods inside a residential area. Plus, like the Wiki says, neighbourhoods can be a mix of different landuses. So not rendering place=neighbourhood names on polygons encourages bad tagging practices.
Possibly related to #2816 since it was mentioned there, but that issue is about rendering larger aras like place=village and similar tags. Which are different then neighbourhoods and have harder to determine boundaries IMO.
The text was updated successfully, but these errors were encountered: