On 10/07/2020 12.22, Clifford Snow wrote:
Interesting suggestion. The sumo github page doesn't appear to have any
open issues that involve OSM and intersections that I could find. (I only
looked at intersection issue titles) Has this been reported to the sumo
developers? Sumo documentation does suggest fixing OSM issues but other
than that it seems to indicate that OSM data is suitable for use with their
software.

I haven't reported anything yet, but (obviously?) it is my intention if this gains any traction to improve SUMO to automatically merge intersections based on this tag. That said, if you watch their *tutorial* (it's over an hour long), there is at least one example where the presenter shows an instance of this issue, so it *is* known to the community. I'm not sure if anyone else has had the idea to specifically annotate these in OSM in order to be able to better fix up such intersections automatically.

For my specific use case, it's moderately important to be able to convert OSM data into SUMO networks in a fully automated and deterministic manner.

Another issue, that isn't really OSM's fault, is that SUMO likes to add intersections wherever a way is split, even though only two edges come together. I don't think OSM needs to change anything there, however, except perhaps that it might be desirable to mark nodes where a U-turn is specifically legal.

You mention that the duplicate traffic signals are a problem but I don't
understand from your proposal how traffic signals should be tagged in your
proposal. Could you update your proposal to include how they are to be
tagged as part of the intersection.

That's because the proposal isn't proposing to change how signals are tagged. Rather, the objective is to make it so that "the existing way" ("each [intersection] node is tagged as a traffic signal") Just Works™ with tools: "signals do not apply to a way which is tagged junction=intersection".

*Independently*, I am leaning toward suggesting to tag signals at the 'stop here' line rather than on the intersection nodes (which also solves the signals aspect of the problem in a different manner), but IMO that is orthogonal. See e.g. https://www.openstreetmap.org/node/7695739446. (Also, if this proposal is approved, that change may or may not be necessary or desirable. I think the 'stop here' lines should be tagged in *some* manner, but with junction=intersection, it may be that a new way to tag 'stop here' lines is desired and leaving the signals on the intersection nodes is preferred. At that point, we're getting into arguing about tagging where the signal *applies* vs. where the actual signal lamp is physically located.)

--
Matthew

_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to