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

Place=suburb should maybe be rendered at higher zoom levels #2546

Open
fqdb opened this issue Jan 9, 2017 · 7 comments
Open

Place=suburb should maybe be rendered at higher zoom levels #2546

fqdb opened this issue Jan 9, 2017 · 7 comments

Comments

@fqdb
Copy link

fqdb commented Jan 9, 2017

In most places around the world, a suburb is an area with a significant population, which may be much higher than that of a town. Currently, suburb labels are rendered from level 12 and up, whereas town names are rendered from level 8 already. In zoom level, suburbs appear at the same time as villages, which obviously have less importance in most cases.

In contrast, the transport layer renders suburb labels from level 10 already, which looks much more balanced.

Or am I interpreting the meaning of place=suburb wrong? For example,in this case the 'suburb density' is much higher, and what I propose here would not have any effect, as long as suburbs are rendered at lower priority than towns.

ZL11
ZL12
ZL13
ZL11 (transport)
ZL12 (transport)

@kocio-pl kocio-pl added this to the Bugs and improvements milestone Jan 9, 2017
@jojo4u
Copy link

jojo4u commented Jan 13, 2017

Place=suburb would need a better specification for this change. Currently it is used for a very wide range of subdivisions. I drafted a hierarchy of urban place subdivisions. Suburb would only be used in cities. Towns would use the smaller place=quarter. https://wiki.openstreetmap.org/wiki/User:Jojo4u/place_hierarchy This draft was presented in german forum but did not gain any response :/

@ligfietser
Copy link

Please render place=quarter. It is a missing link between neighbourhood's and suburbs, in the Netherlands it would be a good tag to map the difference between buurten (neigbourhoods) and wijken (districts) but until now it isnt't rendered at all.

@pnorman
Copy link
Collaborator

pnorman commented Apr 28, 2017

This issue is about zoom thresholds for suburb, not adding quarter which is covered by #798

@ArcticGnome
Copy link

I agree. I think all three city subdivisions (neighbourhoods/quarters/suburbs) need to be larger. If that would cause problems, we need a level above suburb.

For example, I'm trying to label parts of the city of Edmonton, Canada. But the rendering size of the names of neighbourhoods would be smaller than features in the neighbourhood, like parks. So, I've called neighbourhoods "quarters" (like Ekota) and I've called quarters "suburbs" (like Knottwood). However, that leaves me with no label for the next level up (like Mill Woods).

In some cities, editors get around this problem by labelling the larger city subdivisions as "towns", which render at map level 11. But that solution is technically wrong for a place like Mill Woods, which is definitely a suburb of Edmonton and not its own town.

@jeisenbe
Copy link
Collaborator

@ArcticGnome please do not tag places improperly because of our rendering.

the rendering size of the names of neighbourhoods would be smaller than features in the neighbourhood, like parks

Do you mean that the font size is a smaller point than the font used for a large park? Can you show an example of where this is a problem with the correct tagging?

I see "Mill Woods Sports Park" near this area - it is about 1/2 the size of the Ekota neighborhood - is that what you meant?

@mboeringa
Copy link

So, I've called neighbourhoods "quarters" (like Ekota) and I've called quarters "suburbs" (like Knottwood). However, that leaves me with no label for the next level up (like Mill Woods).

This is typical "tagging-for-the-renderer". I understand the desire, but I would recommend you to change it back to the original tagging. Not doing so, will make sure any other map than this one displays the data wrong because you entered it wrong.

@ArcticGnome
Copy link

I see "Mill Woods Sports Park" near this area - it is about 1/2 the size of the Ekota neighborhood - is that what you meant?

This is typical "tagging-for-the-renderer". I understand the desire, but I would recommend you to change it back to the original tagging. Not doing so, will make sure any other map than this one displays the data wrong because you entered it wrong.

I was the person who originally gave labels to Edmonton neighbourhoods. One could make reasonable arguments for calling them either neighbourhoods or quarters. I chose to call them place=quarter because the text for neighbourhoods is so small. In your example, the text for Mill Woods Sports Park and Ekota are reasonably-sized relative to each other now, while Ekota is tagged as a quarter. But if I had used place=neighbourhood instead, the text for Ekota would have been too small.

Calling Edmonton's smallest divisions place=quarter isn't wrong, per se. The problem is that it only leaves me with one rank above. I called Knottwood (the area that Ekota is in) place=suburb. But I have nothing to call Mill Woods (the area that Knottwood is in). Now, I have Mill Woods tagged as place=borough, but as I understand it, there is a push to replace all place=borough tags with place=suburb tags.

I've seen a similar problem play out in other cities. For example, in London, England, OSM calls the city's top-level subdivisions place=town, even though they are part of the city. Subdivisions of these "towns" are called place=suburb, and London makes little or no used of the place=neighbourhood tag.

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

8 participants