split way: wrong position of new member in route relation in loops

[skyper]

What steps will reproduce the problem?

1. have a route relation going through a loop in backward direction
2. split a way in the loop

What is the expected result?

the proper position is automatically chosen in order to keep the connectivity

What happens instead?

the wrong position is chosen and connectivity is broken

Please provide any additional information below. Attach a screenshot if possible.

I gonna attach an example file​.
Please, split the way at the stop position "A" and watch the relation.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-08-05 20:49:54 +0200 (Mon, 05 Aug 2019)
Build-Date:2019-08-06 01:30:53
Revision:15283
Relative:URL: ^/trunk

[skyper]

example file

[GerdP]

The example file contains a relation which is already "unordered"

[GerdP]

No, sorry, the order is probably correct, but the relation editor shows no continuous line.

[GerdP]

This seems fixed, at least the relation order is correct after splitting with r16223. I guess r15943 fixed it?

[skyper]

extended example

[skyper]

For PTv2 and relations without roles it works fine, superb, thanks a lot.

One minor issue remains in my eyes. I have extended the example with two more PTv1 relations B1 and B2.

1. Open relation editors for both relations
2. Split at node B and node A or first B and than A
3. Sync relations in relation managers
4. Have a look at the order of the ways

I expected to find the same order of members with role backward instead the order in B1 is upside down. With the oneway=yes this does not make sense at all but the oneway does not have to be present in this kind of situation, so we cannot relay on it.

[GerdP]

Sorry, I don't know much about roles in route relations. My understanding is that B1 is already broken. Is that intended?

[skyper]

Replying to GerdP:

Sorry, I don't know much about roles in route relations.

Not that easy topic and you are not the only person. One reason for the lacking support in many applications.

My understanding is that B1 is already broken.

Not for a PTv1. JOSM's connection test does not support PTv1 completely, if loops or variants are involved. Rules for ways are (​Tag:route=bus#Members):

• one or both directions in one relation
• possibly, several or all variants in one relation
• use empty role or route for ways traveled in both direction
• use forward/backward for ways traveled only in that corresponding direction

Is that intended?

It is an edge case but valid as example. At least with variants and both directions in one relation, you will find this or more complex situations in data. Anyway, does it matter if the relation is unordered or broken? Should we not try to preserve as much as possible instead of adding to the chaos?

[GerdP]

Anyway, does it matter if the relation is unordered or broken? Should we not try to preserve as much as possible instead of adding to the chaos?

Sure. I just don't know how it should look like ;)

[skyper]

The connection test does not support the loop if it is traveled only in one direction for all variants.

As already mentioned in comment 4 the order of the three backward members should be like in B2 in any cases of a situation where the available data shows a "oneway" situation. This means the members should stay in a order where only the left direction branch is present. Hope that helps

[GerdP]

The current code in SplitWayCommand doesn't evaluate the oneway tag and it also seems to ignores the role (backward/forward).
I don't know what to do with B1. The split-way is connected to the same way on both ends, so looking at the previous member gives no info unless we take oneway info into account. The next way in the member list is not connected to the split-way, so also no info from here.
It could help to look at the oneway attribute of the previous way.
OTOH the oneway tag of the split-way says you cannot travel in that direction.

[skyper]

Replying to GerdP:

The current code in SplitWayCommand doesn't evaluate the oneway tag and it also seems to ignores the role (backward/forward).
I don't know what to do with B1. The split-way is connected to the same way on both ends, so looking at the previous member gives no info unless we take oneway info into account. The next way in the member list is not connected to the split-way, so also no info from here.
It could help to look at the oneway attribute of the previous way.
OTOH the oneway tag of the split-way says you cannot travel in that direction.

You can use backward/forward to get the direction of travel. As said before, the situation is valid without oneway=yes but the roles forward/backward include all the information we need.

[GerdP]

So you think the existence of a role=forward/backward means there is no need to look at other members?

[skyper]

extended example with dual-way situation

[skyper]

Replying to GerdP:

So you think the existence of a role=forward/backward means there is no need to look at other members?

No, we need to look at the members to find out if it is a "oneway or "dual-way" situation. As long as there is no other way without forward/backward sharing an end node in between the line/string of members with role forward/backward. I have added a version 3 of the example file which includes two dual-way relations C1/C2.

[skyper]

There are more complex example. Gonna try to make a complete example file, tomorrow.

[GerdP]

Is it really possible to verify these relations? We have to look at direction of ways, roles, oneway attributes, probably also special oneway attributes like oneway:bus, oneway:psv etc for a bus relation?
If I got you right even gaps might be correct?
It seems likely that those relations are broken ;)

[skyper]

Multi variants and description

[skyper]

I have added josm_18018_example_v4.osm.bz2​​ with descriptions and two more interesting split nodes C, D and E. Relations D1/2 are demonstrations what is valid according to the wiki and found in data.

• All relations are ordered as much as possible, if you want to test with unordered relations, please, add some chaos.
• All relations except A are dual-way.
• B1/2 and C1/2 could be single or multi variant while D1/2 are clearly multi variant.
• B1/2 clearly show a "oneway" situation at node A and B
• C1/2 and D1/2 show rather a "dual-way" situation at node A and B

This ticket is about B1/2. C1/2 and D1/2 are out of the scope and can probably not be well handled.

Replying to GerdP:

Is it really possible to verify these relations? We have to look at direction of ways, roles, oneway attributes, probably also special oneway attributes like oneway:bus, oneway:psv etc for a bus relation?

Connectivity and sorting in JOSM does not work completely. See #6166, #6920, #8019 and #14711 for sorting and #10004, #7681 and #17899 for connectivity.
Oneway is important for connectivity arrows and routing (validator) but not for splitting and preserving the order.

If I got you right even gaps might be correct?

Yes, for PTv1 with variants and e.g. road if there is a gap like many B* (Bundesstraße) in Germany. (Not talking about "link" or similar.)

It seems likely that those relations are broken ;)

• PTv1 is broken in connectivity cause forward/backward and variant/variant:forward/variant:backward or similar were never completely supported or not supported at all, and PTv2 is not was for a long time badly or not supported by data consuming software like the public-transport-renderer. Duplicate members with possibly different roles are still not nicely handled in JOSM, atm. Still PTv1 is widely in use. Speaking for route=bus and considering the last ten years, it will take ten more years until all variants will have their own relation.
• linkin road relations are ok, but still lack some support.

[GerdP]

OK, thanks for the examples. My first thought: "Don't waste time on that. It' not the software, it's the concept that is broken"
I have to sleep about this ;)

[skyper]

Replying to GerdP:

OK, thanks for the examples. My first thought: "Don't waste time on that. It's not the software, it's the concept that is broken"

With country side bus routes having 20 or more variants in each direction it is quite complicated to map PTv2, especially, if you do not have any digital material about the complete routes and their variants, to use. Mapper start to collect data in parts and one relation with all stops and all variants plus at least the direction of travel is a way to start. Sure it makes problems with QA and detail information, though, other schemes have other problems/disadvantages in some persons` perspectives.

I have to sleep about this ;)

I wish you wonderful dreams.

[GerdP]

OK, up to now I only understand A :(
No idea how a bus driver can follow the other relations. Unfortunately the wiki only explains how public_transport:version=2 should be mapped. This looks straightforward and simple. Your examples for public_transport:version=1 all look broken to me. I assumed a gap means something like "make a u-turn and follow the last visited members in reverse order" but that seems to be wrong.

• Please explain what you mean with "dual-way" relations. Could not find the word dual in the wiki about route relations.
• What is a "oneway" situation?
• Which of the examples shows that looking at a given role forward/backward alone doesn't work?
• I don't understand the roles in C2, or better, I don't understand the route at all. The first members go south or east, then it jumps back and the next members finally arrive at the same point, but with questionable roles.

[GerdP]

I've now found that the English and the German wiki are very different.
​https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
​https://wiki.openstreetmap.org/wiki/DE:Tag:route%3Dbus

So, it seems PTv1 is really unordered by concept and I would not even try to maintain or find any order.
My Conclusion so far regarding split way:

• role forward/backward means PTv1 is used. We can use the role without looking at other members.
• public_transport:version=1 means we can ignore the order

[skyper]

example where splitting "backward" needs a neighbor

[skyper]

Sorry, had not much time and always hit bugs these days. This is the third time, I try to answer. Finally, I had to fix relations first and all the validator warnings took some time.

Replying to GerdP:

I've now found that the English and the German wiki are very different.

Yes, sadly, a lot of documentation of PTv1 was removed from the wiki and the content is spread among several pages.

So, it seems PTv1 is really unordered by concept and I would not even try to maintain or find any order.

B2 and C1/2 are ordered and connected.
I would not say unordered but not in the form you expect it. It is more a collection than a straight route where all members are connected to their neighbors. The direction of travel is indicated with roles but ways do not have to be added more than once even if the way is traveled several times or/and the way is part of several variants. In fact, there existed even a warning about duplicated ways, for quite some time, and JOSM still does not support duplicates, weel, e.g. #4798 and some other tickets. It still makes sense to order the ways by connectivity as much as possible.

My Conclusion so far regarding split way:

• role forward/backward means PTv1 is used. We can use the role without looking at other members.

Forward/backward are used in more relations like route=road and neighbors are important for situations where both directions are in one relation and the different ways are traveled for each direction. At the first/last way of a branch before both directions come together to use the same way in different directions we need to look at the neighbors. Additional, branches with mixes of forward/backward are problems. Also, have incomplete relations in mind. Have a look at josm_18018_forward_example.osm​ and split at node "Split".

• public_transport:version=1 means we can ignore the order

This makes working with the relations more complicated as more chaos might be added. Remember that PTv1 is used for all traffic_modes and other routes like bicycle have the same problems. See ​osmwww:relation/17777 for example.

Replying to GerdP:

• Please explain what you mean with "dual-way" relations. Could not find the word dual in the wiki about route relations.

Ok, we have dual-carriage-ways. There the ways are used in only one travel direction separated for each direction. Here we have two branches.

• What is a "oneway" situation?

A loop which is traveled all the time in one direction despite having both directions in one relation. So only one branch for all directions, like B1/2.

• Which of the examples shows that looking at a given role forward/backward alone doesn't work?

I fear all examples are too condensed and we do not have the case of incomplete relations. Had to find a real world example, see above.
This is valid for all routes with two directions not only PTv1.

• I don't understand the roles in C2, or better, I don't understand the route at all. The first members go south or east, then it jumps back and the next members finally arrive at the same point, but with questionable roles.

You are talking about D2, right. C2 is ordered and connected.
D2 could be one variant with several loops or several variants in one relation. The route could first go north to south, taking the small loop in the middle to stop at A and go back to the roundabout and all the way south. Come back north to the roundabout and take the small loop in the middle to the east to stop at A. Then go back to the roundabout and south to go east all the way on the next intersection. Come back again and take the shortcut to stop at A and go to the roundabout leaving north to go east all the way at the next intersection and come back again. All this could be one loop which branches north/south or east of the data.

OK, up to now I only understand A :(
No idea how a bus driver can follow the other relations.

The driver is usually following only parts of the relation as we have two directions with possible variants in one relation, see above.

Unfortunately the wiki only explains how public_transport:version=2 should be mapped. This looks straightforward and simple.

As already mentioned, we need complete information to map with PTv2. Have a look at ​osmwww:relation/69742 or ​osmwww:relation/69754 where I tried to map all variants (probably already outdated as my tools to show the differences of the gtfs-files do not work that well, so far). This was only possible with gtfs and all the public-transport renderers I know do not offer interval or opening_hours as information.

Your examples for public_transport:version=1 all look broken to me. I assumed a gap means something like "make a u-turn and follow the last visited members in reverse order" but that seems to be wrong.

With variants in one relations a u-turn is possible at every way with empty role or route and where branches connect. Gaps are caused by variants and that no duplicate ways exist in these relations but with a smarter connectivity test not only looking at neighbors but at end nodes and allowing more than two (with forward/backward more than four) ways to connect there could be no gap.

[skyper]

See ​osmwww:relation/3385101 and ​osmwww:relation/68320 for some relations with variants. Note, some variants of both relations are already in different relations but this is informal and not the truth as there is no difference in ref and all belong to one bus line.

[skyper]

Replying to skyper:

…
As already mentioned, we need complete information to map with PTv2. Have a look at ​osmwww:relation/69742 or ​osmwww:relation/69754 where I tried to map all variants (probably already outdated as my tools to show the differences of the gtfs-files do not work that well, so far). This was only possible with gtfs and all the public-transport renderers I know do not offer interval or opening_hours as information.

Note, that these routes are inner city lines and no county lines which are often more complicated.

[GerdP]

OK, let's go back to C2. I open this relation in the relation editor and select the members starting from the top. I see how the ways are highlighted. In a complete and ordered relation I would expect that the way 1 is connected with way 2, way 2 is connected with 3 and so on. In C2 the first 4 ways are connected, the 5th way is not not connected to the 4th.
So for me the relation is not ordered. When you write that it is ordered I feel stupid.
I have no idea how data consumers use the information in these relations and why data should be ordered, not talking about how to order.
A turn restriction relation can be ordered but there is absolutely no need to do it. What's different here?

[skyper]

Replying to GerdP:

OK, let's go back to C2. I open this relation in the relation editor and select the members starting from the top. I see how the ways are highlighted. In a complete and ordered relation I would expect that the way 1 is connected with way 2, way 2 is connected with 3 and so on. In C2 the first 4 ways are connected, the 5th way is not not connected to the 4th.
So for me the relation is not ordered. When you write that it is ordered I feel stupid.

Please, not. Are we talking about the same file josm_18018_example_v4.osm.bz2​? Please, download again from the server.

I have no idea how data consumers use the information in these relations and why data should be ordered, not talking about how to order.
A turn restriction relation can be ordered but there is absolutely no need to do it. What's different here?

• Turn-restrictions are tiny, compared to routes with hundreds or even thousands members.
• Turn-restrictions are usually complete downloaded while route relations are often incomplete.
• Split-way for turn-restriction has its own treatment already.
  • If via is one or several ways we already get trouble and connectivity/order comes into play.
• QA for turn-restrictions works but QA for routes does not as all the broken road or bicycle relations show where some small parts are missing. Often due to splitting with incomplete data.
  • ATM, the only way is to manual check within the relation editor looking for gaps. This only works if the relation is order as much as possible with a few gaps and you will fail if you only find chaos.
• Correcting an intersection by splitting the entry and exit into separate ways to map the traffic island in between is almost impossible with chaos, as all members are somewhere in the list and ordering is not possible with incomplete members. In the end, you will add more chaos or you`ll need to download all members first.

[GerdP]

Please, not. Are we talking about the same file josm_18018_example_v4.osm.bz2​? Please, download again from the server.

I've double checked and yes, I am talking about this version.
I think I am the wrong person for this. I've never mapped a route=bus relation. You are probably 10 steps ahead.
Is C2 describing two alternative ways how the bus goes from the northern point to the south-east or does it also describe the way back to the north? With the latter the roles would make sense.
Edit: Yes, now I found a hint in the german wiki "Folgende zusätzliche Mitglieder bei Routenrelationen, die für Hin- und Rückrichtung nur eine Relation verwenden. Für ÖPVN-Routen ist dies veraltet (PTv1)."
So, I made one step forward.

[skyper]

screenshot of C2 in relation editor

[skyper]

This looks like connected for me. Hovering the mouse over the connectivity tree will additionally give some info but only for one branch/direction.

Sorry, mapping bus routes over ten years now, I always forget how much I am familiar with route relations. Yes, one big problem is that some people did tidy up the wiki without looking into data and documenting the state. PTv1, even for bus, is still in major use and removing the information about it instead of documenting the status quo does not help.

• PTv1 can include both directions in one relation.
  • Not very special as this is allowed for all other route relations.
• PTv1 can include variants in one relation.
  • Quite special. Only hiking routes did include variants but they are mapped in own relations these days and superroute is used to collect them.

I fear almost all developers of OSM-Editors did not map many bus routes. So, please, go ahead and ask questions. If you think it is too demanding and you like to spend your time on different tickets/issues I can understand it and have to wait then until someone steps up.

[GerdP]

OK, I'll keep asking, but this afternoon I'll be cycling ;)

[skyper]

Enjoy the holiday and the weather.

To differ relations between both directions in one relation and only one direction per relation, you can look at the tags to and from which should be only present for relations with only one direction.

[skyper]

See #19217 for another problem under different conditions.