New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't split a junction=roundabout way when adding turn restrictions to connecting ramps #6711
Comments
Example object, a roundabout with one way segment: https://www.openstreetmap.org/way/86211544 After adding a turn restriction the roundabout way is split to 3 parts, see in movie below. |
@sun-geo Is it a problem for roundabouts to be multiple segments? |
Ah yeah this makes sense. I think it might have to do this, in order to avoid situations where from/to ends up as the same member. |
There is no hard problem, but there are some thoughts about this situation:
[1] https://www.openstreetmap.org/way/86211818 |
I wrote a bunch more about this on #4848 about why this is tricky problem and why the turn restriction editor is greedy about splitting ways into identifiable segments. In the above example the roundabout doesn't strictly need to be split when adding an only restriction from the oneway turn channel to southbound road, but I can imagine many other situations where it would need to be split up (any roundabout - bidirectional road junction). So I'd really prefer to leave the code the way it is. |
It isn’t workable to require
I don’t think it’s a problem for routers, but it would throw you off if you were trying to find the number of roundabouts in an area by counting Splitting the roundabout into three parts is less optimal than splitting it into two parts, but it’s easy enough to combine the two non–relation members into a single way afterwards. |
@bhousel said:
I agree. The current behavior might not be ideal in all cases but I wouldn't call it wrong. Relations are an advanced level of mapping so I think it's okay to leave individual mappers with the decision to re-merge the ways or not. |
This is ridiculous. iD clearly kills relations going through that roundabout and is it considered "low impact" and "won't fix"??? |
Let me chime in: this is a problem in multiple levels. First and foremost: the editing user is unaware that they split the junction. This is very wrong: the editor should act on users' behalf and not start editing "automatically". Second: if the local OSM editors decide to use a valid method then people breaking it up will have to be reverted, which causes serious friction with new and inexperienced users (who are usually the main group using ID). It is bad for both wastig the time of old editors and severely disappointing new ones. Third: relations are broken apart. If it cannot be cleanly reverted it may cause serious amount of work. Please consider to fix this, or pop up a warning to the user that "You are about to split the junction and ruin relations, the community will tear you apart, would you like to continue and suffer: yes/No?". |
Here is a quite fresh changeset and the result: All public transport relations were valid 2 days ago in the area. Then iD came and exploded the roundabout. |
If the example in #6711 (comment) is representative, the problem was exacerbated by the fact that the roundabout was mapped as a single way in the first place. Ideally, the roundabout should be mapped as multiple ways because of the 30 road and public transport routes that traverse it. Each route would traverse only a portion of the route, omitting any segment that the driver is not expected to take. Instead, each route is looping back on itself at this roundabout. This approach is apparently not forbidden. However, without extra heuristics, it is indistinguishable from cases where the route actually requires looping around. Some routes actually do that in reality, which is the reason why OSMI checks the order of members in a route relation. But I assume that a bus isn’t supposed to complete a full revolution around this particular roundabout before continuing. Unfortunately, it’s well-documented that splitting a way along any route that loops back on itself will shuffle the route’s members out of order: #8415 #8578. The shuffling would occur whether the user splits the roundabout manually or iD does it automatically when creating a turn restriction. The OSMI screenshot above appears to be complaining about the resulting mess. By the way, there’s still an open issue about this splitting behavior: #8213. These extra examples are helpful, but it isn’t necessary to dramatize the problem statement on this older issue. |
Note: The wiki was modified recently in order to unvalidate this issue. I don't like this. However, splitting a roundabout is wrong if you have relations on it. For example when the roundabout is part of a road (
Let's supposed the following situation:
What you really want is:
Please note that there are roundabouts with huge amount of relations like this one with 194 relations. Adding an extra turn restriction here with iD makes a disaster in the area. |
The route relations were already broken by not having the roundabout appropriately split in the beginning. |
I find this assertion bizarre. A road route does not go around the entire roundabout, only the portion that traffic actually traverses on through routing. |
Now I’m confused. The passage that got changed in that diff isn’t even relevant to this discussion. The previous wording says “Do not split the roundabout itself” in order to clarify the bullet point above it, which discusses “splitting” the approaching way into a dual carriageway when there’s a flared approach, versus keeping it as a single carriageway with a Few if any of us who write the wiki have formal training in technical or legal writing, so sometimes a specific passage can be poorly worded. Unfortunately, this problem wasn’t caught before it caused some misunderstanding.
I’m also unsure why this passage was quoted above. It’s specifically about giving all the ways of the roundabout a consistent Meanwhile, the article about route relations has documented the existence of two mapping styles since 2014. It explains the downside of mapping the roundabout as just one way, as I tried to above. This is also closely related to the question of which parts of the roundabout to tag with For the avoidance of doubt, I’m not saying everything is perfect as is. It would be wonderful if iD could avoid munging the order of members of a looping route, and also very nice if it could choose more logical places to split a roundabout when asked to. But those issues are already tracked in active issues awaiting technical solutions. Once the member ordering issue gets addressed, I suspect the kind of blowback described in #6711 (comment) would become much less likely. |
If a roundabout with one or more routes going through it has been properly split to map these routes, then any further splitting should not damage the route relation(s). The issue only occurs if the route relation is wrong (roundabout not split) in the first place. |
This is incorrect. For route relations, both methods (splitting the roundabout and only including the used parts or including the whole un-split roundabout) are valid and routing as well as editing software need to support both because both methods are in widespread use. I'm not arguing in favor of any one particular method here, but editors need to consider this and prevent breaking the routes when roundabouts are modified (i.e. re-assigning route members appropriately when a roundabout is split). The argument that this is a problem with the pre-existing data is just shifting the blame (and isn't correct anyway, see above). Note that other editors (e.g. JOSM) also have similar issues in this situation (although JOSM does handle route relations a lot better in general). |
See title/subject - if you can't reproduce, I will search for an example later.
The text was updated successfully, but these errors were encountered: