This whole "trying to cram everything including direction and how it relates to everything into a node" idea is fundamentally hosed. Also literally why relations are a thing that exist.
On Tue, Oct 9, 2018 at 5:26 PM yo paseopor <yopaseo...@gmail.com> wrote: > > > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
