I’ve published a text log of unsynchronized data where human wisdom is needed and the bot will not automatically edit. For each error, we either need to fix our version, or mot need to fix theirs.
I’ll see if I can easily convert this to a map with points view via Leaflet.
Once we fix our side, we could in principle send the remaining errors back to mot if they’re cooperative.
Edit: the first number is the “ref” value. The last couple of stops have strange ref values like ref=(dan=3937)
Edit 2: Many conflicts are “style/taste” differences (e.g. transliteration schemes or using single quotes or double quotes). I’ll manually edit OSM to match MOT version for cases where it’s a trivial style difference.
I have a fundamental question: Preusmably, whatever name value is in the gtfs is the actual value printed on the stop sign. So, should users really ever change that? Even if the bus stop name is “Road X stop 2”, which is a total mistake because that road was renamed to Y, that stop name is on the ground, written on the sign, making it the true name in accordance with global name tag conventions.
I agree. But I wonder, in practice, how many of the above discrepancies are actually mappers reading mismatching data from stop signs and then changing the stop.
Let’s not have 3 datasets, 2 are complex enough, and let’s just assume that the GTFS name is identical to the physical stop signs. If a mapper ever encounters an exception we’ll handle it individually.
Under that assumption, is there an agreement that GTFS should always override user changes for name tags? (NOT location)
Every override would still generate a log message, to warn the provider of an error if present, and to contact the user if needed.
Let’s just keep it as it is and just add a clear guideline: name = what’s on the sign. When a mapper overrides a GTFS name, I contact them asking if this was an armchair guess or a legit survey. If no reply / not a survey, put GTFS back in, otherwise do nothing; it’s a GTFS error (or send it upstream if we ever establish a communication channel with MOT).
The update is currently underway. Some manual intervention is required in some cases:
The removal of stops that are part of route relations causes JOSM conflicts that I’m manually resolving. For most routes I am simply removing the stop from the route.
Many routes are possibly out of date. No one is actively maintaining them.
There were other minor conflicts that were trivial to resolve (e.g. user adding stops as members of highways).
Can upload issues cause this? The JOSM upload was interrupted multiple times, and I switched the chunk size in the midst of the upload at some point in an attempt to mitigate interruptions.
No duplicates appear for me when I run the script on a local copy of the older stops.
There are cases where people have glued bus stops to roads. The bot moved some of those stops, dragging the road along with them. I am manually fixing these cases one by one. See also this discussion: https://www.openstreetmap.org/changeset/49148167
I am fixing this now. For anyone who has done fixes: Please make sure that after the fix, the stops remains precisely where the bot has moved it, the exact same coordinates.