Automated incremental Bus Stop (GTFS) updates

Thank you for the feedback.

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.

This would mean the gtfs should override the users’ edits in almost all cases in the above log

Presumably, but not necessarily; the MOT database could potentially be out-of-sync with respect to the on-the-ground signage.

I agree that the name of the bus station is whatever is printed its sign (#505 in http://media.mot.gov.il/PDF/HE_TRAFFIC_PLANNING/tamrurim2010.pdf)), even if streets have since then been renamed. In your example, the bus station could be tagged addr:street=Y.

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.

Scratch that. I’m thinking out loud.

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).

Seems fine, as far as I can see.

Thanks!

I’ll be running the script live in a week or so, unless there are objections or reported problems.

Edit: rephrased to reflect newer info.

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).

Update complete. This is a massive update because it’s the first one. From now on there will be weekly updates that are much smaller.

Changesets:

I’ve come across some duplicate bus stop nodes in Ramat Bet Shemesh.

http://overpass-turbo.eu/s/sLK

I have no idea if this is an isolated case.

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.

This is not an isolated case. There are 295 cases. Apparently the first chunk was uploaded twice or something like that. I will try cleaning this up.

Fixed in https://www.openstreetmap.org/changeset/53524487

If someone can explain how and when this occurs, I’d appreciate an explanation to avoid this in the future.

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 believe I fixed all of them. But this could have ended up worse. I’ll need to take stops glued into roads into account the next run.

http://www.openstreetmap.org/way/280293501 - here stop glued to the park…

Oh man, I was focused on roads.
I’ve fixed that one. Thanks!
I’ll make a more thorough cleanup this weekend or if I have the time before the weekend.