Another point worth thinking about: At the moment, OSM only has the Hebrew names for the bus stops, but the GTFS file also contains translations of these names from Hebrew to English and Arabic (see translations.txt).
When importing stops, it’d be a good idea to import their translated name too, if one exists.
Another point worth considering regarding “- - X” is West Bank area C. Do they have marked bus stops? Do they have their own ref system? If so, the rules inside area C should never be “delete” for “- - X” (for bus stops lacking israel_gtfs), regardless of what they are in Israel. Luckily we have the proper relations to do this easily if needed.
Good point! I’ll first finish the “minimum viable product” and then see if I can implement this.
You’re correct about area C.
I think the safest way would be to never delete any bus stop that doesn’t have source=israel_gtfs - this way we’ll be sure we don’t destroy Palestinian bus stops or private shuttle bus stops.
There are 1573 bus stops without a “ref” tag that the script completely ignores. What should we do with them?
When the script first runs, it’ll create duplicates that do have a ref tag for most of those stops. Some of the ones that won’t have a duplicate created may be long gone.
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.