On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr <o...@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.¹ > It is > - Tag the node as traffic_sign=<ISO>:<ids>. > It is > - As with your suggestion, <ISO> is the ISO country code. > It is > - <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 :4 subkeys > - 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. > > https://wiki.osm.org/Proposed_features/direction#Point_features > > 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. > > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging > > 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 > separately. > 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. yopaseopor > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
