Thank you for the insight. I don’t know that it is off topic though as any tagging scheme should be both achievable by a typical mapper and useful to any anticipated data consumers. Something that is easy for taggers but not useful to data consumers is just noise. Something that is useful for a data consumer but hard for a mapper is, well, a hard problem.
In this case, it seems that adding a “direction = forward | backward” tag to a node also tagged with “highway=stop | give way” is just noise. > On Mar 17, 2017, at 7:38 AM, Daniel Hofmann <hofm...@mapbox.com> wrote: > > On the routing engine side these tags will be translated to turn penalties > for specific turns, so the matching equivalent would probably be from,via,to > relations. Which is not a feasible modelling in OSM realistically speaking. > Simple stop signs could go on ways, but fail to capture more complex > situations. > > The problem with traffic lights specifically is their interconnectivity: you > don't want to add turn penalties multiple times if traffic lights are > connected. But you can't tell. This is a bit off-topic, feel free to > cross-post to the osrm-talk or routing mailing list, or open an issue in > osrm-backend. > > On Fri, Mar 17, 2017 at 3:29 PM, Tod Fitch <t...@fitchdesign.com > <mailto:t...@fitchdesign.com>> wrote: > From a data consumer point of view, what type of tagging would be reasonable > to indicate the, for lack of a better work, direction of travel a stop, give > way or traffic light has effect? > >> On Mar 17, 2017, at 3:54 AM, Daniel Hofmann <hofm...@mapbox.com >> <mailto:hofm...@mapbox.com>> wrote: >> >> Jumping in here to give a perspective from a routing engine (OSRM, >> https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine >> <https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine>). >> We do not handle direction tags on nodes which indicate a property for a way >> or a turn at an intersection. The example with stop signs and give yield >> signs is spot on. Even worse is the assumption that routing engines can just >> infer the direction by checking the distance to the nearest intersection. >> This is in conflict with how parsing and creating a graph works. >> >> There is a similar problem with exit_to node tags, indicating the exit way >> destination - you can read about it here >> >> - https://www.openstreetmap.org/user/daniel-j-h/diary/40555 >> <https://www.openstreetmap.org/user/daniel-j-h/diary/40555> (en) >> - https://www.openstreetmap.org/user/daniel-j-h/diary/40554 >> <https://www.openstreetmap.org/user/daniel-j-h/diary/40554> (de) >> >> Cheers, >> Daniel J H >> >> >> On Fri, Mar 17, 2017 at 11:25 AM, Martin Koppenhoefer >> <dieterdre...@gmail.com <mailto:dieterdre...@gmail.com>> wrote: >> >> 2017-03-16 5:13 GMT+01:00 Tod Fitch <t...@fitchdesign.com >> <mailto:t...@fitchdesign.com>>: >> The “direction” tag [1] has different uses that seem disjoint to me. >> To specify the orientation (compass point or degrees from north) of an >> object (adit or cave entrance, etc.). >> >> "orientation" would have been a better descriptor IMHO, but the crowd uses >> this tag differently (see taginfo, also subtags like roof:orientation, ...). >> Direction is working for me nonetheless. >> >> >> 2. To specify direction (clockwise/counterclockwise) around a roundabout >> (not sure why this is needed as it should be apparent from local laws or >> specified with a “oneway=yes”). >> >> >> agree with you >> >> >> 3. To indicate the direction (forward/backward) a stop or yield (give way) >> sign has effect along a way. >> >> >> broken. From time to time people are coming up with features to tag on nodes >> that require (or seem to require) the information of a direction. Taking the >> direction of a different object (e.g. here a way) doesn't seem a healthy way >> to represent this. Ways might get split, might get reversed, nodes might be >> (or become) part of several ways, etc. Either use a cardinal direction or a >> short way stub or a relation, etc., but not "forward" or "backward" tag >> values on a node, it simply doesn't make sense. Tags should refer to the >> object they are tagged on. >> >> >> >> Oddly, that third use seems only for stop and yield signs but not for >> traffic signals where a “traffic_signals:direction=forward | backward” tag >> is to be used. However that seems to be the most used form [2]. Apparently >> some have figured that if we have “traffic_signals:direction” there should >> be “stop:direction” [3] and “give_way:direction” [4] tags. >> >> >> similarly broken >> >> >> I would keep the variant 1 and discourage 2 and 3. >> >> Cheers, >> Martin >> >> >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> >> https://lists.openstreetmap.org/listinfo/tagging >> <https://lists.openstreetmap.org/listinfo/tagging> >> >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> >> https://lists.openstreetmap.org/listinfo/tagging >> <https://lists.openstreetmap.org/listinfo/tagging> > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/tagging > <https://lists.openstreetmap.org/listinfo/tagging> > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
