(Sent again, this time without all the cc: which probably are the cause of the previous attempt being held in the listserv's spam filters... After eleven hours I guess it won't be delivered to the list so I resend)
On Fri, 24 Mar 2017 19:08:13 +0100 yo paseopor <[email protected]> wrote: > > I would start a "definitive thread" with all the options, all the > possibilities, all the points of view, all the information and then, > passing all to the wiki with a votting or aproved by list complete > proposal. Well, heres is an attempt... At some point one may wish to paste it into a wiki page. In cc: the participants in the threads recently discussing this subject. So, here is a summary of the methods that, after discussion here, seem to have some traction among participants for the mapping of "stop" restrictions and similar restrictions such as "give_way" and "traffic_signals". This is about the restriction, not the sign that advertises it. It applies to two-ways way, in cases other than an all-ways restriction. I omitted some methods mentioned which seem too ambiguous, too heavy on processing, lacking current use or all of the above. ---------------------------------------------------------------- 1- highway=stop+direction=forward node on the way to an intersection Documented at https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop and https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way Advantages: - Only one additional tag - Uses the widely used direction=* tag Disadvantages: - To be unambiguous, must be tagged on a non-intersection node adjacent to the intersection to which it applies - Only good for covering simple cases: complex case require a more powerful method such as the relation (type:enforcement) - direction=* is also used for cardinal directions, so two semantic fields coexist within the same tag ---------------------------------------------------------------- 2- highway=stop+stop:direction=forward node on the way to an intersection Documented at https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals Advantages: - Only one additional tag - Uses the *:direction=* scheme which is widely used for traffic_signals:direction=* and stop:direction=* and might therefore be unified later. Also used for railway signals. - Cognate to the way Kendzi3D models signs Disadvantages: - To be unambiguous, must be tagged on a non-intersection node adjacent to the intersection to which it applies - Only good for covering simple cases: complex case require a more powerful method such as the relation (type:enforcement) ---------------------------------------------------------------- 3- relation (type:enforcement) Documented at https://wiki.openstreetmap.org/wiki/Relation:enforcement Advantages: - The only method to unambiguously covers all cases - Few additional tagging steps: creating the relation and adding a couple members covers the simple case - Compatible with the node bearing the highway=* restriction being either on the way or elsewhere at the actual location of the sign Disadvantages: - A couple more additional tagging steps compared to the other methods - It is a relation (relations are perceived as not beginner-friendly, and some consumers don't grok them) My opinion is that method #3 must be promoted but current practice hints that it might have to coexist with one of the two others (or both if no convergence consensus emerges). _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
