The gtfs file contains all national railway station refs. The script has been modified and it now ignores them as a temporary solution.
As for the deleted stop: Note that it’s present in the intermediate layer, (…_script1), I’m still trying to optimally tweak the duplicate removal algorithm (_script2), but it is impossible to make it remove duplicates whilst always knowing which one of the two stops has the right position. Even an armchair mapper cannot do that. However, If you ever move that newly added stop to the right position, the bot will not insist on moving it back and all will be good. (It would also generate a message in a log, that perhaps can someday be sent upstream to mot).
Lastly, to minimize similar deletion damage, if that stop had any extra tags whatsoever (shelter / ref / name / etc), it wouldn’t have been removed and would have been marked with a fixme instead.
I think the tradeoffs are optimal that way and that the de-duplication step is necessary. Please let me know if you have improvement suggestions, or if you find anything else that is interesting in the test files.
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