Open osm-ToniE opened 1 year ago
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.
It is like a closed way in OSM: start and end are the same
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=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.
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
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:
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