Curtis Brown <[email protected]> writes: > I am genuinely curious to know from OsmAnd developers what their point of > view is. Does OsmAnd's routing prefer traffic_lights moved out of > intersecting nodes of dual-carriaged intersections, or does its routing > treat a cluster of traffic_light'd nodes as a single weight?
I don't know, but you should understand that it's not really ok to adjust tagging based on what osmand does. My understanding of traffic light tagging is that there should be highway=traffic_signals at road junctions, such that any traversal of the intersection that encounters a signal in reality will traverse one in the representation. And, that paths through in the representation that hit multiple signals should not be penalized more than hitting one. That's partially because when there are multiple signals they are coordinated. The simplest case to illustrate this is a dual carriageway with a single carrriageway at right angles, with a light. There should be a highway=traffic_signals at each of the two junctions. But, on turning left (assuming US drive-on-right), one will not be controlled by or delayed by the other one, because if you have a left green arrow, the other one is ok. It seems obvious that a router should behave reasonably with any tagging scheme that has significant use, or it's broken. Now, if there is a consensus among 80% of the routers out there, that's sort of a de facto tagging semantics definition. But you can't (properly) just adjust to what osmand wants. Keep in mind that there is a lot of wiki fiddling, so that what's in the wiki may represent a paper exercise by someone separate from how the tags are actually used. The proper forum for arguing about how signals should be tagged is [email protected]. -- You received this message because you are subscribed to the Google Groups "Osmand" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/rmi5znpaczu.fsf%40s1.lexort.com.
