Render *_name=* or *:name=* if there is only one and no name=*

[Penegal]

Hello, there.

The title says it all: when there is no name=*, but only one among *_name=* and *:name=*, it should be rendered instead. That would encourage contributors to fill these fields instead of name=*, when the value is supposed to not be in name=* but in another one. One example I have in mind is substation or transformer names: to highlight the fact that the name belongs to the substation or the transformer and not to the building containing it or the pole supporting it, it should be mapped as substation:name=* or transformer:name=*, but naive contributors could think that, as the name is not rendered, it should be put in name=* in order to be rendered. Rendering the way I suggested could remove this assumption, and ultimately improve modelling.

Regards.

[matkoniecz]

That is not a good place to invent a new tagging.

substation:name tag at this moment is used 0 times worldwide - see https://taginfo.openstreetmap.org/keys/substation:name

transformer:name is used 1 time according to https://taginfo.openstreetmap.org/keys/transformer:name#overview

Please, propose, discuss and promote new tags on tagging mailing list and/or OSM Wiki and/or local forums.

[dieterdreist]

2017-11-08 8:32 GMT+01:00 Penegal <notifications@github.com>:

Hello, there. The title says it all: when there is no name=*, but only one among *_name=* and *:name=*, it should be rendered instead. That would encourage contributors to fill these fields instead of name=*, when the value is supposed to not be in name=* but in another one. One example I have in mind is substation or transformer names: to highlight the fact that the name belongs to the substation or the transformer and not to the building containing it or the pole supporting it, it should be mapped as substation:name=* or transformer:name=*, but naive contributors could think that, as the name is not rendered, it should be put in name=* in order to be rendered.

If you need tags like "substation:name" there is typically something wrong with your modeling. You should better have an object in OSM for the substation and one for the building (if the spatial extension of 2 areas is the same, you could for example use a multipolygon with one outer way, or overlapping ways, or a node inside the building (the latter doesn't convey information about the extension though). This will avoid ambiguities. Having both, a building and a function, represented by the same object is leading automatically to ambiguity, even if a human or a sophisticated heuristic might often be able to interpret it correctly. I know that it is done very often as a shortcut, but this doesn't mean there aren't problems.

[SomeoneElseOSM]

Ignoring substations and transformers for a second, there are places where it might make sense to display something other than "name". Here's an example: https://www.openstreetmap.org/way/407193053#map=18/52.94161/-1.13238 . As an example, it might make sense to use "lock_name" there instead of "name" and incorporate the ref. The result is https://map.atownsend.org.uk/maps/map/map.html#zoom=20&lat=52.9416056&lon=-1.132346 and it was done via lua in https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1152 .

Separately to that there are lots of things in this style that don't get names at all but arguably should - but that's a whole other issue.

[mboeringa]

This is also a wholly impractical suggestion. There is a million potential keys out there that could potentially be used in a

KEYNAME:name

or

KEYNAME_name

construct.

Which one would need to be rendered, how would you ever decide? (everyone will have its own pet project...) Does a renderer need to check all million keys?... Renderers using a non HSTORE database, won't even be able to access them, as the data simply won't be there...

I also think the type of data you want to store, is often more suitable for the "ref" tag. Substations likely don't have a real name, but more likely a coded value for administrative and management purposes. Or if they do have a name, they are likely to have a ref as well for the same reasons.

[SomeoneElseOSM]

I'd reject the idea that something that I've actually done is "wholly impractical" :)

Of course it's importany define which objects we're interested in rendering other names for (ones actually in widespread use in OSM data), which the initial comment didn't, but that doesn't mean that the idea is impractical.

[matkoniecz]

Note that lock_name and similar may be discussed in their own separate issues, maybe some issues already exist for this ideas.

Closing this is not rejection of rendering name label using tags other than name in any situation.

[dieterdreist]

2017-11-08 10:37 GMT+01:00 SomeoneElseOSM <notifications@github.com>:

Ignoring substations and transformers for a second, there are places where it might make sense to display something other than "name". Here's an example: https://www.openstreetmap.org/way/407193053#map=18/52.94161/ -1.13238 . As an example, it might make sense to use "lock_name" there instead of "name" and incorporate the ref.

It's the typical situation of a property used to map something indirectly. Yes, as long as you map things (only) as properties of other things, it is desirable to render those subkeys. It isn't without alternatives though: you could also map an area for the lock and put the name there, or represent it with one or 2 nodes or an explicit relation for the lock (e.g. linear with the waterway as member, or both, with an area as well), etc.. A similar situation was there with bridges: until we introduced man_made=bridge people used bridge_name to indirectly refer to a bridge from the way on the bridge. There might be cases where it makes sense to have the feature referred to by another feature (IMHO locks on a waterway are such a case), but it should be evaluated carefully, because it poses other problems (like the one we are discussing here), as mboeringa points out, there are infinte variations of names of implicit things, and we won't render all of them. It also doesn't stop at "name", if you have an article in Wikipedia for the lock and one for the waterway, you 'll have to use lock_wikipedia, and for the ref lock_ref and if the lock is younger than the waterway lock_start_date, if there's a different operator lock_operator, etc.

[HolgerJeromin]

lock_name is "discussed" here #157