[Tagging] Route names that aren’t names

[Peter Elderson]

Suggestion for rendering:

What about osmc:name=*

I know, doesn't exist, but it's a logical companion of osmc:symbol.

Definition would be: name to show on the map.
Definition should be: just the simple name as found in the field, or the
nae ecerybody knows and uses, no extra's.

As with osmc:symbol, it's not mapping for the renderer, but mapping for
rendering.
Implementation rule for the renderers: if exists osmc:name <use it>, else
<do what you do now>.

Best, Peter Elderson


Op wo 1 apr. 2020 om 12:23 schreef Richard Fairhurst <richard at systemed.net>:

> Yves wrote:
> > Inevitably, the current situation is stained by the abilities of the
> > actual renderer, and the other way around. Maybe those renderers
> > should sit around a wiki page and document how ideal tag could be
> > and how they can be used in rendering, also taking into account
> > the ability to parse nested relations or not with their respective
> > toolchain.
>
> With my cycle.travel hat on: I already show route refs (as shields). I
> would
> like to show route names without duplicating the ref or showing extraneous
> information. I don't really mind whether the tag is name= or official_name=
> or route_name= or brian= or whatever. Parsing nested relations is no
> problem, I already do that.
>
> To be honest, I'm perfectly happy to sit down for a day, armed with a bunch
> of regexes, and go through the current list of names to get alternatives
> that I can hard-code into cycle.travel. But that doesn't help anyone else!
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200401/a8e7ed71/attachment.htm>