osm-relatify
osm-relatify copied to clipboard
Zaczero
Do not split Roundabout
Hi,
A much discussed topic and in my opinion without a clear answer is whether due to a relationship (in our case a bus line) a roundabout needs to be split into several segments. Some say no, because for them the roundabout is a single element, not to be split. It would be nice if each user could decide how to manage roundabouts on their own lines.
What do you think?
In my opinion, I think the route should not contain any road parts which the bus does not traverse through. But also:
Consistency Some roundabouts are not simple. Roundabouts can be massive and complex and applying the same rule there wouldn't make much sense. By applying the same process to each roundabout, the map becomes more consistent and standardized.
Technical simplicity By having a single road processing rule: always split at intersections, the code is easy to maintain and understand. No matter the circumstances, be it simple or complex roundabout, it always follows the same logic.
There is no official guideline to split roundabouts for bus routes so this tool should not recommend this and should also not show intact roundabouts as "not used ways". By the way this tool tends to create overlapping roundabout segments if it splits roundabouts.
There is no official guideline to split roundabouts
The guidance is here: https://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_and_roundabouts .
It allows splitting roundabouts as one of two valid ways to map bus routes: "The roundabout is split and the part used by the bus route is included in the route relation.".
In the absence of consensus, I think it is valid and reasonable for users and application developers to split or not-split as they prefer. The guidance gives suggestions to developers of systems that consume route data of either type; it makes it seem that non-split roundabouts are harder to deal with in some circumstances.
If the tool is creating overlapping roundabout segments, then that is a Problem. Do you have examples?
Yes exactly, and as there is not only "one" way about how to proceed in this case your tool should be neutral and not prefer one or the other way. As it is now, your tool irritates beginners as they do not know the background.
Regarding examples, there have been some changes made recently by "ManueleRa" which I fixed today and guided me to the discussion here. You can still see the corresponding error view of OSM inspector showing those issues at the roundabouts (blue markers), but they no longer exist in the database:
https://tools.geofabrik.de/osmi/?view=routing&lon=8.99012&lat=45.84921&zoom=13&baselayer=Geofabrik%20Standard&opacity=0.60&overlays=duplicated_edges%2Cunconnected_open_ends_1
More or less all segments of the split roundabouts were duplicated and one of these doubled items was a member of one or more bus routes. In one example one segment was assingned to one group of routes and the other segment assigned to an other group of routes. If I remember correctly this here was the corresponding example:
https://tools.geofabrik.de/osmi/?view=routing&lon=8.97734&lat=45.86514&zoom=17&baselayer=Geofabrik%20Standard&opacity=0.60&overlays=duplicated_edges%2Cunconnected_open_ends_1
Yes exactly, and as there is not only "one" way about how to proceed in this case your tool should be neutral and not prefer one or the other way. As it is now, your tool irritates beginners as they do not know the background.
Or, to put it another way, Relatify is following one of the correct methods. I think we're just going to disagree on this point - you're saying that because two valid method are available, Relatify should chose the low-detail method. I'm saying it's OK for it to chose the high-detail method.
Regarding examples, there have been some changes made recently by "ManueleRa" which I fixed today and guided me to the discussion here. You can still see the corresponding error view of OSM inspector showing those issues at the roundabouts > (blue markers), but they no longer exist in the database:
Thanks for the examples - I hope the developers will be able to confirm the problem and fix it.
Digging into this a bit, I've built a query for OSMCha that shows Relatify-made changesets which created new objects, made by Manuel Ra: https://osmcha.org/?filters=%7B%22users%22%3A%5B%7B%22label%22%3A%22Manuele%20R%22%2C%22value%22%3A%22Manuele%20R%22%7D%5D%2C%22editor%22%3A%5B%7B%22label%22%3A%22osm-relatify%20%22%2C%22value%22%3A%22osm-relatify%20%22%7D%5D%2C%22create__gte%22%3A%5B%7B%22label%22%3A%221%22%2C%22value%22%3A%221%22%7D%5D%7D
There are 7 in total, so it should be easy to spot Relatify messing up.
This roundabout has double segments: https://www.openstreetmap.org/#map=19/46.20287/9.01496
This roundabout has double segments: https://www.openstreetmap.org/#map=19/46.20287/9.01496
Looks like the two ways were created by two different Relatify sessions: https://www.openstreetmap.org/way/1236982793 (Changeset #145892098 ) https://www.openstreetmap.org/way/1237024972 (Changeset #145892193 )
The two changesets were closed about 3 minutes apart - is it possible that you had two Relatify sessions open at the same time, both of them thinking there was a single Roundabout object? E.g. e.g. you saved the second one, it didn't know that the first one had already split the roundabout?
Shouldn't relatify implement an optimistic locking in that case and deny updating in case the versions of ways to split have changed, instead of ~~blaming~~ putting the burden on the user?
instead of blaming the user?
For clarity I did not blame anyone for anything and I do not consider that anyone has done anything blameworthy.
It is possibile that i had open the two different directions at the same time... The same direction twice i think not...
The roundabout duplication bug is known to me: https://github.com/Zaczero/osm-relatify/issues/32. I am currently focusing on NG (https://github.com/Zaczero/openstreetmap-ng) development which one of the goals is to create API 0.7. The new API release will remove dependency on overpass and simplify big chunks of the synchronization code. I could fix it now, but that's not my priority and doing it after the NG will require less work in total. At the moment, I believe it's more feasible to wait for NG and then fix all the issues manually or automatically. You have my word that I will correct all the map issues which are the result of this bug. 🦀
The easiest solution for now is just waiting i.e. 3-5 minutes before next relation edit in relatify. New data need this time for propagation to Overpass server.