Skip to content
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

Closed
Adamant36 opened this issue Mar 23, 2020 · 12 comments
Closed

Render name on place=neighbourhood polygons #4090

Adamant36 opened this issue Mar 23, 2020 · 12 comments

Comments

@Adamant36
Copy link
Contributor

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.

@jeisenbe
Copy link
Collaborator

This is a duplicate of #103

@Adamant36
Copy link
Contributor Author

Adamant36 commented Mar 24, 2020

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?

@jeisenbe
Copy link
Collaborator

#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.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Mar 24, 2020

I checked the current use of place=neighbourhood in several regions:
https://wiki.openstreetmap.org/wiki/Talk:Tag:place%3Dneighbourhood#Review_of_usage_on_areas

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.

@Adamant36
Copy link
Contributor Author

Adamant36 commented Mar 24, 2020

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.

@imagico
Copy link
Collaborator

imagico commented Mar 24, 2020

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.

@Adamant36
Copy link
Contributor Author

Emphatic +1 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.

@jeisenbe
Copy link
Collaborator

get rid of the border around landuse=residential when its co-tagged with place tags

That would be a separate issue

mapping them that way would involve "nesting landuse"

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.

@Adamant36
Copy link
Contributor Author

Adamant36 commented Mar 25, 2020

What do you mean? Each landuse=residential area can be mapped as a separate closed way or multipolygon to represent the area.

From my understanding not within another landuse=residential area though. Otherwise, your double mapping it over the larger one. Like if you mapped a mall as building=retail and then a store inside of it as another building=retail area or something. Your not suppose to add it as an additional tag to administrative units even if it was proper to map them inside each other anyway though.

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.

Yeah, but I'm not a big fan of it or anything for the reason I stated. Like with these two apartment complexes it look like they have a barrier around them when they don't have one due to the border. Although it is lighter then the fences, but it could still confuse people in cases where there isn't a fence to compare the lighter shade to. Also, the Wiki says not to use landuse=residental to make things at the parcel level. So, I'm not a big fan of it because of that either.
Apartments

That would be a separate issue

I think it's related as far tagging places as residential landuse like you recommend to make the label render would give the false impression of a border that might not exist (although that could go for landuse=residential areas in general I guess). Which wouldn't be an issue if the label where just rendered on places mapped as areas. Plus, the Wiki explicitly says not to use landuse=residential "as additional tag for urban administrative units."

My calculation here is what's better, rendering labels on place=neighbourhood even though there areas might not be 100% precise in some cases, or using a non-approved work around, that leads to mapping residential areas inside of other ones (plus gives the impression of a border that might not exist and could potentially be confused with a barrier) just so the name will render? Neither one is great, but the first option seems like the better option to me. Especially since like I said already the Wiki explicitly says not use landuse=residential "as additional tag for urban administrative units."

It's also worth mentioning that 414,719 uses of landuse=residential are tagged with the name tag. While there's only 6,190 uses of landuse=residential tagged on places. I'm pretty sure a good percent of those 414,719 landuse=residential areas with names would better be tagged as place=whatever, but aren't because of the lack of name rendering and because you aren't suppose to map landuse=residential by adding it to the place or boundary=administrative tags.

@Adamant36
Copy link
Contributor Author

Adamant36 commented Mar 25, 2020

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.

@siliconninja
Copy link

@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.

It is normal to map boundary=administrative areas which might be the same as the neighborhood, and we do render these.

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.

that leads to mapping residential areas inside of other ones (plus gives the impression of a border that might not exist and could potentially be confused with a barrier)

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".
Here's an idea to render the label of the area better: We could have some sort of algorithm to figure out where to place the label (in the center but not on top of any houses), so at higher zoom levels, you wouldn't see the neighborhood name on top of anything, to make it less confusing.

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.

@Adamant36
Copy link
Contributor Author

Adamant36 commented May 21, 2020

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants