I could do that. Not trivial but not very hard. But it’s only safe for really close stops (e.g. <10m). We can’t know if a 20-meter far stop is a duplicate or a legit stop which is not in the gtfs db. Even manual armchair checks wouldn’t work.
We could merge obvious ones (manually or through a script) and keep the rest, hoping someone will survey them.
Or we could assume that the national gtfs db is perfect. Not in positions, but in bus stop listings, and trust it by removing all ref-less stops after the incremental update is applied. But is it really perfect?
gtfs:id causes confusion. Examples: this bulk edit, editors confusing the two, and me confusing the two while writing the script. Having dual-ids also complicates the incremental updates script unless I ignore one of the ids.
gtfs:id may be needed in the future to grab routes/translations from the gtfs files. This may have been an oversight on my part. If we ever need it I’ll add it back, but it’s likely that I can make the script use it internally where needed without ever adding it to OSM.
Ref is public facing and appears to be permanent, and in case it ever changes, the bot will simply remove the stop and add a new one in its place. A possible drawback is that some values like shelter=yes/no would be lost, or maybe that could be a good thing; if the ref changes, it’s likely accompanied by construction work and change in the physical area, and someone should re-survey to see if the shelter remains or if one has been added. It’d be really strange if they just randomly change a ref without any construction work in an area.
Just in case, I am looking for cases where it actually changed, making sure there are none or very few.
Wrote an experimental script for “merging duplicates”. If X has ref, Y has no ref, and they are closer than the threshold, delete Y.
If the threshold is 5 meters, 46 stops would be deleted.
if the threshold is 50 meters, 1200 (out of 1573 ref-less) stops would be deleted.
100 meters - 1374
200 meters - 1451
Edit: Sorry. That’s the data assuming work is done on the 2012 stops. The numbers are higher if the incremental update is applied first:
One possible “imperfection” from an OSM point of view would be disused/abandoned stops. Suppose the ministry retires a bus stop, meaning buses no longer stop at it, budget is no longer allocated to maintain it, etc; in this case the bus stop might be removed from the db (that’s just speculation; I don’t know for sure), but since the bench and pole wouldn’t go away, it should remain in the map (tagged with a https://wiki.openstreetmap.org/wiki/Lifecycle_prefix).
Good catch. Under the current code, such a stop would be removed. But if someone adds it back it wouldn’t be removed again, because it lacks source=israel_gtfs.
Not all stops have a “platform”. Some of them are literally just a single pole on the side of the road, with no sidewalk. I don’t think we should add public_transport=platform automatically.
public_transport=platform is meant to eventually replace and unify highway=bus_stop, railway=platform, aeroway=gate, etc. The wiki explicitly states that it can be used for “locations where there is no physical infrastructure (for example a customary bus stop without infrastructure or with a pole),”. It’s not about a physical platform.