-- Dave Swarthout <daveswarth...@gmail.com> writes: > This is embarrassing but relevant to this conversation. I've been mapping > intensely for several years but adding stop signs was something I rarely > did.
I only started adding stop signs within the last year. Probably I started because OsmAnd will give a warning, and that's good, as long as there is no one else in the car :-) > In hindsight, it's perfectly obvious when one considers routing engines > that any highway=stop node must affect traffic in both directions unless > made explicit in some fashion, or else ignored as OSMand seems to do. So > far, I've only added 45 highway=stop nodes in Alaska and 18 in Thailand. > I'll be revisiting them to add the appropriate direction tags in the not > too distant future. I don't think it's obvious... For highway=traffic_signals, the normal situation is that it's on a node, and affects all ways entering the node. Or it's on a way and affects both directions -- in my experience, when there are traffic lights not at an intersection, they are always for both directions (even though in theory they could be set up for one direction only). Stop signs, on the other hand, are for the most part sort of properties of intereections, except that the normal cases are that some ways have them and some don't, or that all ways have them. (Around me, some is much more common than all, but all isn't odd.) As a human, if I see a highway=stop on a way about 3-10m from an intersection, it's obvious that it applies to travel on the way towards the intersection, but not leaving the intersection. However, I think OsmAnd sometimes falses on these. I had the impression that there was supposed to be a relation with the intersection node, which seems somewhat awkward. I would suggest a definition that associates the stop sign with the nearest intersection if it's less than 25m away, and there are no intersections in the other direction within 3x that closest intersection distance. And then to use relations to label which intersection, if the above doesn't work. > As to an opinion about how to implement their tagging, I would tend to go > with the ones that resemble the directionality tags already in use for > lanes, i.e., lanes:forward=* and lanes:backward=* except that it's awfully > verbose. I automate much of my tagging with custom presets in JOSM so > adding complicated, long tags to them isn't difficult but asking casual > mappers to enter these very long tags like > "traffic_signals:direction=forward" is going to be problematical IMO. > Consequently, I would lean towards keeping it simple and > using direction:forward/backward to indicate directionality, at least for > nodes. That sounds ok to me too, but it seems that it should be mostly unnecessary. I view this whole exercise as designing tagging rules that are good for human editors and acceptable (semantically non-kludgy and reasonably easily implementable) for data consumers.
signature.asc
Description: PGP signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
