osm-relatify
osm-relatify copied to clipboard
Zaczero
Relatify breaks a correctly and completely mapped round-trip route relation
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
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.
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.
This duplicated stop case kinda make sense only if you were to use _entry_only _exit_only roles.
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.
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:.
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=bus_stop 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.
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.
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.
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.
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).
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 🤔.
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.
