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 <rich...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
