Relatify breaks a correctly and completely mapped round-trip route relation

[osm-ToniE]

https://relatify.monicz.dev/?relation=3548588&load=1

and save and see the OSC file in JOSM

It is correctly and completely mapped as of 2023-06-30 00:15 AM

It corresponds to this route given as GTFS https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?feed=DE-BY-MVG&release_date=&trip_id=4.T0.3-58-G-013-1.6.R

• deletes the first stop and makes the second one the a stop_entry_only
• changes role stop to stop_exit_only on the last stop
• deletes many of the public_transport=platform from the relation
• breaks the round-trip into a start and stop (with respect to the stops)
• keeps the round-trip based on member ways

[Zaczero]

I am working on this issue and I have a question:

How confident are you in the first/last bus stop being repeated in round-trip routes? This seems quite strange to me: https://www.openstreetmap.org/api/0.6/relation/3548588. Shouldn't a proper solution indicate each bus stop just once and use the roundtrip=yes tag as per https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus#Tags? I couldn't find any specific documentation on that.

[Zaczero]

Because it looks like it's stopping at the same bus stop twice per single round. And roundtrip=yes would imply that the route continues indefinitely.

[Zaczero]

This duplicated stop case kinda make sense only if you were to use _entry_only _exit_only roles.

[osm-ToniE]

I can answer only today using a smart phone an will be back Friday next week.

The PTv2 https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726 doesn't say anything about roundtrip I guess. So, you need to have first and last stop to define the same, independent of entry or exit only.

[osm-ToniE]

It is like a closed way in OSM: start and end are the same

[Zaczero]

I just released an update which makes handling of this case quite better. I decided to rely on the roundtrip=yes tag in the relation to change the behavior of _entry/_exit roles and similar. I feel like it's the best solution for now, in the future we could implement some checkbox in the tags view to quickly toggle on and off this flag.

https://www.openstreetmap.org/node/728736776 In cases like this, the platform can't be used as it's being shared by multiple stopping positions with a highway=bus_stop tag. To resolve it, highway=bus_stop should be moved off stopping position to a side as per https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop.

Missing platforms were due to highway=bus_stop set on stopping positions, not platforms. While developing Relatify I incorrectly assumed that if highway=bus_stop is set on a stopping position, then there must be some poor tagging and I didn't bother for checking for existing platforms. I improved this logic to be more optimistic.

Some stopping positions/platforms may be incorrectly grouped as there is not much to go by. The primary logic is to try grouping by name + local_ref, then it fallback to minimal distance sum algorithm. Nothing new here, just a small reminder.

Let me know if you still have any concerns with this route :+1:.

[osm-ToniE]

Sorry for the late reply, I've been in hospital. Just in brief, w/o checking the relation further:

I just released an update which makes handling of this case quite better. I decided to rely on the roundtrip=yes tag in the relation to change the behavior of _entry/_exit roles and similar. I feel like it's the best solution for now, in the future we could implement some checkbox in the tags view to quickly toggle on and off this flag.

I wouldn't rely on [roundtrip=yes] as it is not mentioned in the so called PTv2 proposal.

https://www.openstreetmap.org/node/728736776 In cases like this, the platform can't be used as it's being shared by multiple stopping positions with a highway=bus_stop tag. To resolve it, highway=bus_stop should be moved off stopping position to a side as per https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop.

+1

Missing platforms were due to highway=bus_stop set on stopping positions, not platforms. While developing Relatify I incorrectly assumed that if highway=bus_stop is set on a stopping position, then there must be some poor tagging and I didn't bother for checking for existing platforms. I improved this logic to be more optimistic.

Well the phrase "_The highway=busstop tag is widely used on a node off to one side of the highway way to identify the position where passengers wait for a bus beside the carriageway." is relative new I suppose. I did not see that in 2017 or so.

I'm pro to see this. But the reality is a bit more complex:

highway=bus_stop is defined on nodes only, so not allowed on ways and areas. So: fits best for a node on the road, where the bus stops. People often map public_transport=platform as way or area, so they would have to add an extra node for that (I don't have problems with that).

On the other side, highway=bus_stop is not a part of PTv2 (only for backward-compatibility though?), so why bother about that? From my point of view: it just defines where the bus icon will be placed on the "Carto" map stile, not more.

Some stopping positions/platforms may be incorrectly grouped as there is not much to go by. The primary logic is to try grouping by name + local_ref, then it fallback to minimal distance sum algorithm. Nothing new here, just a small reminder.

Yep.

Let me know if you still have any concerns with this route +1.

I'll check during the next days, can't sit longer than 5-10 minutes.

[mxxcon]

Relation https://www.openstreetmap.org/relation/2944257 is a round-trip I mapped it using relatify, confirmed all the stops are properly selected, all the ways are properly selected to created a route loop, set starting and ending way, but Geofabrik Inspector tool complains that a bunch of stops are in the wrong order and there's a route gap with ways.

[osm-ToniE]

Agreed, from the first review in JOSM, the relation is OK. PTNA would find some issues and report them, but PTNA is not (yet?) configured to analyse NYC - so I can't judge

• is "Mermaid Avenue & West 17th Street" eastbound really the first stop and the last stop of the "round-trip" as printed on paper, can be seen in PDF time tables?
  • just considering that a new driver starts his shift at this location, the current one leaves the bus?
  • just considering that a bus will be replaced by another one before running out of gas, people have to exit
• if so, the "Mermaid Avenue" should be split at that stop_position and
  • the "Mermaid Avenue" east of that stop_position should be the first member way in the list
  • the "Mermaid Avenue" west of that stop_position should be the last member way in the list
• if not, apply the above said to the right stop

I don't know why OSM Inspector complains (based on old data, you might have to wait 24 hours after edit?).

complains that a bunch of stops are in the wrong order

That's a very tricky analysis and IMHO will produce many false positives.

[mxxcon]

No, "Stillwell Terminal Bus Loop" is the first and last stop. The ways are already split at its stopping position and marked as start/end with Relatify. Yet Relatify for some reason didn't put that stop as first and there's no way to change that.

[Zaczero]

No, "Stillwell Terminal Bus Loop" is the first and last stop. The ways are already split at its stopping position and marked as start/end with Relatify. Yet Relatify for some reason didn't put that stop as first and there's no way to change that.

You can manipulate first stop by adjusting the Start/Stop position for the route :smiley: (right click on way).

[mxxcon]

No, "Stillwell Terminal Bus Loop" is the first and last stop. The ways are already split at its stopping position and marked as start/end with Relatify. Yet Relatify for some reason didn't put that stop as first and there's no way to change that.

You can manipulate first stop by adjusting the Start/Stop position for the route 😃 (right click on way).

Yes, I already did that, yet apparently stop order is incorrect and Relatify sees nothing wrong with that 🤔.

[mutipg]

https://relatify.monicz.dev/?relation=9156542&load=1

Roundtrip in Relatify actually works problematically. Using the example relation 9156542 above, I want to show how the bus route is damaged:

• Figure 1 is a bus route in JOSM, which is correct.
• Figure 2 shows how 'Relatify' sees it before sending the changeset - the list is missing the stop "Usedom, Schule" as the final stop.
• Figure 3 is the result of updating the roundtrip route by 'Relatify' in JOSM, where the stop 'Usedom, Schule' is placed in the middle of the route.

Figure 1

Figure 2

Figure 3