Named shop and named building tagged as one object may display name twice

[EdLoach]

Example:
http://www.openstreetmap.org/way/139582259#map=17/51.94532/1.28870
shows the name Cutaway twice

[matkoniecz]

I think that it is a data issue. According to current tagging both building and shop are named "Cutaway" - and in that situation this rendering is correct. One label is for building, one for shop.

[EdLoach]

If the building contains a shop or amenity then the name tag applies to the shop or amenity. If the building had a name as well it would form part of the postal address and belong in addr:housename (which is where P2 always puts the "Building name" when entered on the address tab in Simple mode). Perhaps if I add the address tags to the building it will be clearer (though in this case it has a number, 10, rather than a building name).

[matkoniecz]

If the building contains a shop or amenity then the name tag applies to the shop or amenity.

Is it documented somewhere on wiki? AFAIK http://wiki.openstreetmap.org/wiki/Key:name never mentioned restrictions like that.

[EdLoach]

Not specifically on that page, but things like bridge_name have come about because you can't easily add the name of the bridge and the name of the road going over it in one name tag. One example page which says to use addr:housename for the building name is where the station name is on the building - http://wiki.openstreetmap.org/wiki/London_public_transport_tagging_scheme

[pnorman]

No, the tagging looks fine. The issue is one of label collisions. The shop icon collides with the pub mug, so isn't rendered. This leaves open enough space for the name to render as a building name.

One possible technique is to render a transparent icon, setting it to render regardless of collisions, to put its bbox in the collision detector.

[matthijsmelissen]

I agree this is a rendering problem, not a tagging problem.

[matkoniecz]

It may be duplicate of #234 (in case that rendering building name and icon with its label would be OK).

[dieterdreist]

sent from a phone

Am 02.08.2015 um 01:19 schrieb math1985 [email protected]:

I agree this is a rendering problem, not a tagging problem.

buildings with shop tags on them are also a tagging problem and likely cause ambiguities as soon as some detail is tagged - unless all properties belong to the building and the shop at the same time.

Yes, it is done nonetheless very frequently. But still merits to be discouraged.

[pnorman]

It may be duplicate of #234

Solving #234 is the appropriate route to solve this, so closing this as a duplicate.

[dieterdreist]

Am 01.08.2015 um 21:54 schrieb EdLoach [email protected]:

things like bridge_name have come about because you can't easily add the name of the bridge and the name of the road going over it in one name tag.

bridge_name is not a tag to put on a bridge, it is a tag that gets attached to a part of a bridge (a way that runs on a bridge, like a road or a railway track).

One example page which says to use addr:housename for the building name is where the station name is on the building -

addr:housename is for addresses, it is not the tag to declare the name of a building (in particular if the building name is not an address).

FWIW, as a rendering style we may decide to interpret ambiguous data in a certain way like giving precedence to building users over the building itself when guessing where to assign the name tag to. Likely this would correctly solve a good majority of all cases currently, and would on the other hand encourage people to continue with this ambiguous mapping style.

[kocio-pl]

I have found another strange case, where building label is used instead of mall label - but only on z=18. What could be the cause?

[matkoniecz]

mall label ha probably higher priority but it would be larger. On z18 it failed to fit with icons and building label was able to fit was it was diplayed.