[Tagging] Traffic_sign discussion
yopaseopor at gmail.com
Tue Oct 9 22:24:28 UTC 2018
On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr <osm at tobias-knerr.de> wrote:
> On 09.10.2018 17:42, yo paseopor wrote:
> > So Please , let's talk about it. What will be the correct way to tag a
> > traffic sign?
> How about the existing tagging scheme for traffic signs on nodes,
> documented at https://wiki.osm.org/Key:traffic_sign ?
> To sum it up:
> - Place a node for the traffic sign into the highway=* way.¹
> - Tag the node as traffic_sign=<ISO>:<ids>.
> - As with your suggestion, <ISO> is the ISO country code.
> - <ids> is composed of one or more country-specific traffic sign ids, as
> an ordered list separated by commas.
It is better to manage the information with each position to avoid the
mixtures. One of the errors of the mass edition were the edition of
ways...with traffic signs tag. If any way would not have this key dedicated
to the nodes there weren't these errors.
> - If there are multiple groups of traffic signs, these groups are
> separated by semicolons.
Each traffic sign can have its position like Finnish people do , with :2 :3
> - Custom inscriptions on a sign are appended to the sign id in square
> brackets .
but which information are these brackets? Are maxspeed values? Are maxleght
values? Are custom inscriptions or designations? It is better to expose
this information with their own keys to process it by the renders
> ¹ The page also documents how to map traffic signs next to the way, but
> I understand you would like to talk about mapping them as part of the way.
Thanks for this consideration
> I haven't seen a convincing reason for changing this yet. I'm aware of
> the general argument against semicolon-separated or comma-separated
> lists of values, but imo this is less critical for keys that have
> well-defined semantics for such characters.
multiple values are a problem for the processing of the data. Nowadays a
lot of values are yes/no, etc. In this way of tagging it is logic to make
the pairs :2 :3 or :forward :backward , etc.
> > traffic_sign:direction=forward/backward/both
> > Also accepts other facing directions like 90/270...
> In my opinion, traffic signs should use the normal direction=* key for
> angles such as 90 or 270. This usage is part of the approved proposal of
> that key:
If direction=0 is forward and direction=180 is = backward ok I'm agree.
Because if it marks the cardinal orientation these direction would change
in every curve making less intuitive the tagging of the direction.
> Using traffic_sign:direction specifically for the "forward" and
> "backward" values, as discussed in the recent iD-related thread, is fine.
Some people does not agree and says the reason of the edition (make the
scheme compatible with iD solution) sucks.
> I find it hard to discuss this proposal because it includes so many
> different ideas:
> - introducing a system of "categories" for signs: caution, warning, etc.
All these categories you can find in every traffic sign's law and also on
the API of one of the possible sources: Mapillary. These keys help to make
human-readable values and also international (because of the people does
not want to use ISO codes) . There are also in OSM some categories like
maxspeed , restriction...
> - using :2, :3 etc. instead of comma-separated ids
Finnish people do so well
> - using human-readable values instead of unambiguous national IDs
It would be an important decision because with country codes we can show
exact traffic sign as it is for the country, not similar: equal.
> - re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
Reusing tags for OSM. Only we have to change some options for validators
> - adding a side=* key
For making a exact position using relatives to the way
> - improving destination sign and roundabout mapping
Destination signs are one of the more important traffic signs because they
show towns, local places which connects to data in real place.
> Trying to change all that at once likely leads to discussions that mix
> all sorts of loosely related topics.
It is true it is complex. But as the topic for me is so important (making a
tagging scheme for a World collaborative project like OSM) that I try to
think ( I have started with this in 2011) how to do it and try and
establish a complete (4 position, 3 panels (12 localizations) in two
directions and two sides with basic colors)
Now we can discuss with a base that works. We can modify all we want, all
we agree, all we think, but we have the base.
> And there's not really a reason why
> e.g. introducing the side=* key would also require using numeric
> suffixes. These are independent changes that could easily be discussed
Well this time I will start all the discussions to find a solution. I don't
want to fight or read things like "sucks" or "stinky". I have dedicate lots
of time, like other people and I don't think I deserve these words.
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging