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 different tags on a node & polygon? #2582

Closed
DaveF63 opened this issue Mar 16, 2017 · 13 comments
Closed

Render different tags on a node & polygon? #2582

DaveF63 opened this issue Mar 16, 2017 · 13 comments
Labels

Comments

@DaveF63
Copy link

DaveF63 commented Mar 16, 2017

Hi
Is there a reason entities with the same tags render different tags depending if their a polygon or node? My initial feeling is the should be consistent.

addr:housenumber=142
name=The Foundry (this is a business name not a building name so can't be addr:housename)
The polygon has building=yes

capture

@imagico
Copy link
Collaborator

imagico commented Mar 16, 2017

We currently render building names only on buildings mapped as polygons.

We could consider changing that but IMO if a mapper wants to specify a name for a building he/she should also be able to map it as a polygon so this seems rather unnecessary.

In your case the name does not seem to be the name of the buildings anyway, it should be something like man_made=works or office=* - which then might or might not be rendered by this style. 😉

@HolgerJeromin
Copy link
Contributor

We have some inconsistencies.
Housenumbers on areas are not rendered. Which is #1746. I just wanted to link those two.

@DaveF63
Copy link
Author

DaveF63 commented Mar 16, 2017

@imagico "this is a business name not a building name"

I also note a node with office=* name=* doesn't render at all.

To me name of a business is more relevant & informative to an end user than a housenumber, on both node & polygon. I think it should be amended.

@pnorman
Copy link
Collaborator

pnorman commented Mar 17, 2017

We render the name of specific objects which are already rendered, which is why a node with building=yes and a name doesn't render. I don't see us changing the decision to tie names to stuff we render, or deciding to render buildings as points.

@imagico
Copy link
Collaborator

imagico commented Mar 17, 2017

Rendering offices is covered in #108 and #1697.

@DaveF63
Copy link
Author

DaveF63 commented Mar 17, 2017

@pnorman I didn't say the node had building=* so I'm unsure if your post is relevant, although it would be helpful if you'd clarify what you mean by "We render the name of specific objects which are already rendered"

To clarify it best I can:
In the real world there are 2 identical companies. In OSM one is mapped as a node, the other a polygon. They share these tags:

addr:housenumber=142
name=The Foundry
office=yes

The polygon has the additional tag of:
building=yes

Rendered results:
The node displays the house number
The polygon displays the name

I believe they should be consistent & display the, more relevant, name tag.

I refer you to this comment for confirmation of my point: #108 (comment)

@imagico
Copy link
Collaborator

imagico commented Mar 17, 2017

@DaveF63 - we got your point but as i explained the name is rendered on the polygon because it is tagged building=yes and we do not really want to render names on buildings tagged as nodes. We probably also do not want to render generic office=yes on either polygons or nodes but rather render a list of specific office types, probably in a generic form.

For this to happen someone needs to develop a suitable styling to render these that integrates well with the rest of the map and someone needs to implement it.

@DaveF63
Copy link
Author

DaveF63 commented Mar 17, 2017

we do not really want to render names on buildings tagged as nodes.

Could you explain why? The inconsistencies of a row of business properties rendered with both name & number, as has been pointed out, looks strange.

if a mapper wants to specify a name for a building he/she should also be able to map it as a polygon so this seems rather unnecessary.

I disagree with this. There should be consistency irrelevant of the way it's mapped.

Take a large building, often with the same address, but divided into individual offices (maybe on multiple floors) the majority of mappers will add each business as a node. If they're tagged with addresses, this carto will just display loads of '142's. Not very helpful.

We probably also do not want to render generic office=yes on either polygons or nodes

  1. The carto already is: address numbers. Why not swap it to the more helpful name?
  2. Assume they're tagged office=software, the argument is still the same.

To be clear, I'm not talking about an icon, just the name label, as it is with the polygon example I've given.

@imagico
Copy link
Collaborator

imagico commented Mar 17, 2017

It seems to me you misunderstood most of what i wrote.

We render features based on their tags and combination of tags. If a feature has a name tag we do not always render the name as a label, we only do so if this is a certain type of feature where we render name labels for and we then do so in a certain styling so the map user can conclude from the way the label is rendered that this is a certain type of feature.

In this case we currently render names on polygons tagged as building (with any value other than no) - which we also render with a filled polygon - the name then is assumed to be the name of the building. And we render house numbers on anything with an addr:housenumber but with low priority so if a building polygon has a name tag and an addr:housenumber we render the name rather than the house number.

We are considering rendering features tagged with specific, well defined values of office=* in a generic form, for example with a dot and a label for the name tag but distinct from other labels so the map user can see this is the name of an office. This would apply to both polygons and nodes

Take a large building, often with the same address, but divided into individual offices (maybe on multiple floors) the majority of mappers will add each business as a node. If they're tagged with addresses, this carto will just display loads of '142's. Not very helpful.

I see no problem here - correctly mapped that is one building polygon with an addr:housenumber and a lot of nodes with office=* and the respective names within that building, possibly with level=* to indicate the floor.

@DaveF63
Copy link
Author

DaveF63 commented Mar 17, 2017

Hi

Still considering the rest of your post, but:

one building polygon with an addr:housenumber

Surely address data has to go on individual the nodes of each business?

@daganzdaanda
Copy link

Hi

Surely address data has to go on individual the nodes of each business?

Yes, that is valid tagging, too.
Right now, this is what leads to the "loads of 142s" that you can see in some places.
But when/if we make the decision to render nodes with the office=* tag with e.g. a dot and the name=* (and someone does the work to implement it), then the name=* should take priority, even when there is a addr:housenumber=*.
Maybe you can help with a pull request so that we could check how it would look? It's not going to be a small change in some areas with lots of details already...

@dieterdreist
Copy link

dieterdreist commented Mar 18, 2017 via email

@imagico
Copy link
Collaborator

imagico commented Mar 18, 2017

I am sorry for inciting a tagging discussion here with my remark - this is not the place for it.

We render addr:housenumber as a label on anything that has this tag and i currently see no good reason to change that. There is an occasional abuse for name dropping but since the meaning of this tag is very specific this is quite rare. Overall this rendering is in line with the wiki and practical use of the tag in most cases.

Since this issue is about rendering building names on buildings mapped as nodes (which i don't think we should do - see above) and on rendering offices (which i think we should do - but there are already issues for that) i am going to close this. Feel free to ask if you don't understand the reasoning or have further reasons why it should be changed, but be specific in terms of practical use cases and how you think it should be rendered please.

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

No branches or pull requests

7 participants