Skip to content
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

Closed
sun-geo opened this issue Aug 1, 2019 · 17 comments
Labels
wontfix-low-impact Doesn't improve the user experience enough to spend time on

Comments

@sun-geo
Copy link
Contributor

sun-geo commented Aug 1, 2019

See title/subject - if you can't reproduce, I will search for an example later.

@sun-geo
Copy link
Contributor Author

sun-geo commented Aug 2, 2019

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.
I think this behavior is the same for v3(preview) and current released v2.15.4.

splitted roundabout

@quincylvania
Copy link
Collaborator

@sun-geo Is it a problem for roundabouts to be multiple segments?

@bhousel
Copy link
Member

bhousel commented Aug 2, 2019

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.

@bhousel bhousel added the considering Not Actionable - still considering if this is something we want label Aug 2, 2019
@sun-geo
Copy link
Contributor Author

sun-geo commented Aug 2, 2019

@sun-geo Is it a problem for roundabouts to be multiple segments?

There is no hard problem, but there are some thoughts about this situation:

  • if an person adds a turn restriction where specific ways are involved[1] than at least I expect no hidden splitting of a way which is not involved[2]
  • a split of a way should be only done - for my understanding - when there is a need to add different tags for the 2 way segments
  • I saw roundabouts where the osm-roundabout-way is part of many relations, if there is a split then there is much more work if there is a map change needed, and there is a higher risk that cartographer miss to add these split way to relations

[1] https://www.openstreetmap.org/way/86211818
https://www.openstreetmap.org/way/86212144
[2] https://www.openstreetmap.org/way/86211544

@bhousel
Copy link
Member

bhousel commented Aug 2, 2019

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.

@1ec5
Copy link
Collaborator

1ec5 commented Aug 3, 2019

It isn’t workable to require junction=roundabout to be a single closed way. A roadway, even a roundabout roadway, can be split for any number of reasons, be it a bus route that only traverses a quarter of the circle, lane counts and turn lanes in a turbo roundabout, or varying sidewalk tags.

Is it a problem for roundabouts to be multiple segments?

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 junction=roundabout ways. In my area, I’ve added each multisegment roundabout to a type=junction junction=roundabout relation. Junction relations make it possible to count the roundabouts more holistically.

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.

@quincylvania
Copy link
Collaborator

@bhousel said:

So I'd really prefer to leave the code the way it is.

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.

@quincylvania quincylvania added wontfix-low-impact Doesn't improve the user experience enough to spend time on and removed considering Not Actionable - still considering if this is something we want labels Aug 7, 2019
@Yogurt4
Copy link
Contributor

Yogurt4 commented Feb 18, 2022

This is ridiculous. iD clearly kills relations going through that roundabout and is it considered "low impact" and "won't fix"???
Just check OSMI after setting turning rules on entrances/exits...

@grinapo
Copy link

grinapo commented Feb 18, 2022

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?".

@urbalazs
Copy link

Here is a quite fresh changeset and the result:

kép

All public transport relations were valid 2 days ago in the area. Then iD came and exploded the roundabout.

@1ec5
Copy link
Collaborator

1ec5 commented Feb 18, 2022

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.

@urbalazs
Copy link

urbalazs commented Feb 18, 2022

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 (route=road) then the whole roundabout should be part of the relation.

If there are several roads of different importance connecting to the roundabout, you should usually use the one with the greatest importance, that does not begin/end at the roundabout. See Selection of the right highway tag.

Let's supposed the following situation:

  1. The roundabout is mapped as one closed line (as the wiki previously asked).

  2. The roundabout is part of a relation (bus, road, no matters).

  3. iD editor explodes the roundabout into 4 peaces (marked with numbers above).

                      ---1--
                     /      \
            <F-<<-- |        | <F-<<--
    ------>         2        4         ------>
            -->>-F> |        | -->>-F>
                     \      /
                      ---3--
    
  4. Piece 2 and 4 are still part of the relation. But the roundabout is not a closed line anymore, so piece 2 and 4 will result gaps in the relation.

What you really want is:

  1. Do nothing for fixing the real issue.
  2. Force the mapper if he/she add a turn restriction THEN take care of the relations AND check all relations affected by the roundabout explosion AND remove the no longer needed members from all relations.

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.

@ElminsterAU
Copy link

The route relations were already broken by not having the roundabout appropriately split in the beginning.
Splitting the roundabout left the route relation no more broken than it was before.

@ZeLonewolf
Copy link

For example when the roundabout is part of a road (route=road) then the whole roundabout should be part of the relation.

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.

@1ec5
Copy link
Collaborator

1ec5 commented Feb 19, 2022

Note: The wiki was modified recently in order to unvalidate this issue. I don't like this.

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 traffic_calming=island node on it. The author clearly meant to keep people from misinterpreting that as requiring the roundabout itself to be split into multiple ways just because of the flare. Otherwise, the sentence would be misplaced and inconsistent with other guidance on the same page, which refers to the “way(s) of the roundabout”, plural.

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.

If there are several roads of different importance connecting to the roundabout, you should usually use the one with the greatest importance, that does not begin/end at the roundabout. See Selection of the right highway tag.

I’m also unsure why this passage was quoted above. It’s specifically about giving all the ways of the roundabout a consistent highway value, as the link clearly illustrates. iD doesn’t appear to be changing highway classifications automatically.

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 ref to indicate that a road route traverses it, which the tagging list explored in 2020.

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.

@ElminsterAU
Copy link

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.

@Woazboat
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix-low-impact Doesn't improve the user experience enough to spend time on
Projects
None yet
Development

No branches or pull requests

10 participants