Israel GTFS release

Can I remove all the auto-added bus-stop fixmes? They are shadowing real fixmes.

Thanks. I will consider that too.

Can I remove the GTFS fixmes? They’re shadowing legitimate fixmes and there’s 30k of them.

+1 from me (for what it’s worth), I agree that they’re shadowing. Will there be another way to identify all the stops that are currently marked fixme? E.g. would they be added to a new ‘stops for review’ relation or something?

They was added to draw an attention of editors to low quality data import. I don’t see any better way of doing this and IMHO, they are not less important than any other fixme. If current gtfs data will be more accurate - we can easily clear all fixmes.

Were there any specific examples of seriously inaccurate GTFS data (e.g. more than 5-10 meters)? Or was it just a general suspicion of the import accuracy?

I can’t give you any exact statistics, but I saw many stops on wrong side of the road and too far from their real location. Even moovit added option to report correct location.

I’ve fixed many stops in Rishon that was on the wrong street side or at another block (it may be 10-20 meters, but if you coming from the side street it will be the right turn instead of left one, and pedestrian turn-by-turn routing will fail in that case)

Is there a way to tag the nodes as ‘position is inaccurate’ in a way that routers, etc will understand? Something like a precision=10m tag?

The vast majority of the GTFS fixmes are false positives. On the other hand the other fixmes almost always require attention.

Maybe we could use another tag, e.g. gtfs:accuracy_fixme/source=“Auto-imported GTFS, check for accuracy!”/precision=10m.

Preferably something already being used.

I’ve asked about accuracy=* on help.osm.org:

https://help.openstreetmap.org/questions/57436/how-to-tag-approximately-positioned-in-a-machine-parseable-way

The discussion is ongoing.

Worth noting this comment by SomeoneElse:

We can combine the methods, e.g., add gtfs:verified=no and accuracy=20m (or whatever the worst-case error is known to be).

fixmes were replaced with gtfs:verified=no. I did not add accuracy because I don’t know the error rates. Changesets: #51169519, #51170352, #51171122, #51174070.

Fixmes down from ~31,000 to 1895. Only 6% of the fixmes left. That’s pretty manageable.

@SwiftFast thanks! (OT: also, thanks for the Daliyat al-Karmel market fix the other day)

Now that all bus stops imported via gtfs have gtfs:verified=no, wouldn’t it make sense to write a script to download the GTFS DB every week, add only update bus stops that have gtfs:id and gtfs:verified=no ? stops move around often (especially in Tel Aviv where there are road works), new stops are regularly added and old stops are regularly removed.

At the moment, OSM has a lot of stops that aren’t there anymore, for example the ones in Petach Tikva’s Jabotinisky middle bus lane (that has been closed for the light railway construction for a while now). Since Israel has so many bus stops, it makes no sense to maintain them manually - no human can track all the changes and keep the map up to date. I know automated edits are generally frowned upon in OSM, but that’s the only reasonable way to keep the bus stops up to date on the map.

Yes, an updating script is needed. It’s on my to-do list. See previous posts in this thread. (Though I’m not sure I agree on the specifics you mentioned. Bus stops without gtfs:verified=no should still receive updates).

I managed to extract bus stops from GTFS and import it into the JOSM scripting plugin. I’ll now experiment with different merging techniques.

Some errors detected so far:


WARN: two osm bus stops same ref. ref=31628, id:1803070181 OR id:518136779
WARN: two osm bus stops same ref. ref=3029, id:1803078612 OR id:1803007057
WARN: two osm bus stops same ref. ref=31395, id:1803085968 OR id:518140581
WARN: two osm bus stops same ref AND gtfsid. ref=15602, gtfsid=27870. id:1803054257 OR id:3725071189
WARN: two osm bus stops same ref. ref=39116, id:454353493 OR id:1803001240
WARN: two osm bus stops same ref. ref=32011, id:458715051 OR id:1803043127
WARN: two osm bus stops same ref. ref=39235, id:542705445 OR id:1803087556
WARN: two osm bus stops same ref. ref=32942, id:1802986047 OR id:941922250
WARN: two osm bus stops same gtfsid. gtfsid=16198, id:1803035944 OR id:1803045065
WARN: two osm bus stops same ref. ref=39306, id:1530647519 OR id:1803080068
WARN: two osm bus stops same ref. ref=9941741, id:1803002992 OR id:4911337809
WARN: two osm bus stops same gtfsid. gtfsid=32804, id:1803002992 OR id:4911337809
WARN: two osm bus stops same ref. ref=39454, id:893250637 OR id:1803005694
WARN: two osm bus stops same ref. ref=39479, id:1803016847 OR id:4298607800
WARN: two osm bus stops same gtfsid. gtfsid=557, id:1803016847 OR id:4298607800
WARN: two osm bus stops same ref. ref=47, id:1803020946 OR id:1803064907
WARN: two osm bus stops same ref. ref=34;35, id:755156662 OR id:752933252
WARN: two osm bus stops same ref. ref=9945554, id:1803040289 OR id:3684783003
WARN: two osm bus stops same gtfsid. gtfsid=33293, id:1803040289 OR id:3684783003
WARN: two osm bus stops same ref. ref=39291, id:1803032401 OR id:1537849739
WARN: two osm bus stops same ref. ref=3;5, id:753080387 OR id:753076542
WARN: two osm bus stops same ref. ref=13037, id:1803001219 OR id:4521026196
WARN: two osm bus stops same gtfsid. gtfsid=26054, id:1803001219 OR id:4521026196
WARN: two osm bus stops same gtfsid. gtfsid=32972, id:1802988407 OR id:2763718615


Here’s a merging idea.

Problem: Dealing with conflicts between mapper edits and gtfs data.
Solution: “The most recent version is the correct version” philosophy.

  • The first gtfs update would update everything. Conflicts are resolved by prioritizing the gtfs file’s version. This is a “necessary evil” but is only needed once. (edit: I might be able to mitigate this by tracing bus stop OSM history).
  • Some time passes, and users update some of the bus stops.
  • The ministry of transportation updates some bus stops in its database and publishes a new gtfs file.
  • The next gtfs update would inspect the difference between the new gtfs file and the older gtfs file. Only bus stops that have had their data (in the gtfs file) changed since the last file are updated. So, conflicts are resolved by prioritizing the gtfs file version, but only for the bus stops that were changed by the ministry since the last update. The rest of the bus stops are left intact.