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

Show both name and housenumber when there's no POI-specific icon available #4216

Closed
Mannivu opened this issue Oct 9, 2020 · 5 comments
Closed

Comments

@Mannivu
Copy link

Mannivu commented Oct 9, 2020

At the moment, Carto shows only the addr:housenumber value when there's no specific icon for a POI. However, this can be really hard for those users that know a POI is around a certain area, they no the POI's name but don't know the address. So, showing the name value (maybe something like "Name; housenumber" or "Name<br/>hosuenumber") would be really useful.

@Mannivu Mannivu changed the title When there's no icon available, show both name and housenumber Show both name and housenumber when there's no POI-specific icon available Oct 9, 2020
@jeisenbe
Copy link
Collaborator

This issue is similar to #962.

We do not show the name=* tag for all building=* features. Only addr:housename is shown for the rare cases where a building as a name used as the mailing address or physical address, rather than a number.

This is intentional, because showing the name=* tag for all buildings will often show the name of a type of feature which is not otherwise supported or rendered in this style. If we show the name= tag in all cases, mappers would be likely to start adding this alone without adding a proper tag for the feature. (See for example #288)

In the past this style used to show many features via “catch-all” renderings, but there was an intentional move to only render specific features (See #1 and #240, and also #3730).

@jeisenbe
Copy link
Collaborator

In our Cartography guidelines, the first purpose of this style mentioned is:

"It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use.”
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

So we should not render everything that has a name, because many tags are typos, mis-spellings, or rarely-used alternatives to more common tags. And rendering the name for any tag will lead to mis-tagging of names to get certain text rendered.

I recommend closing this issue.

@jidanni
Copy link

jidanni commented Oct 18, 2020

All I know is in some cultures that the place is #768 is more important than that it is whatever shop. In other cultures everybody is too busy to know about house numbers, which are viewed only as important to navigation as e.g., gas meter numbers... unless somebody takes the bold step of also showing them on the map, whereupon the public there would slowly start to grasp their usefulness.

@Mannivu
Copy link
Author

Mannivu commented Oct 19, 2020

I can see your point, but I think that on some POIs should display the name instead of the house number. For example, most of the healthcare values don't have an icon so, it would be hard to find them in the map (yes, I know, OSM is a database, but the users should be able to easily find pois in order to fix them).

@imagico
Copy link
Collaborator

imagico commented Oct 21, 2020

A feature tagged with addr:housenumber=* and name=* the name has no well defined meaning. An address has no name. It could be the name of a building (in which case it would need to be tagged building=*) or the name of some other structure/facility present at said address (which would likewise deserve a distinct classifying tag). We should not just render labels for names tagged with unknown semantics because that would incentivize mappers to label things just by adding name tags without additional semantic information (which is essential for interpreting the data).

Therefore closing this. If there are specific feature classes that could well be shown with a name label opening a specific issue for those could be appropriate.

@imagico imagico closed this as completed Oct 21, 2020
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

4 participants