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.
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.
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.
Done. Did I miss anything?
I’ve done lots of duplicate cleanups. As of now we still have 545 bus stops that do not appear in GTFS, most of them are duplicates with the real GTFS stops meters nearby. Most of them are clustered in Jerusalem, Ber Sheva, and Tel Aviv district. If you are familiar with one of those areas, you can help by cleaning up duplicate stops. Most of them are marked with “fixme=Suspected duplicate stop. Flagged by SafwatHalaby_bot (flag-gtfs1).”
I propose the following tagging changes:
Add public_transport=platform, bus=yes, for compatibility with “public transport v2” and for future routes.
remove the gtfs:verified tag. Reasons:
[list=*]
The Israel gtfs database is rather accurate most of the time
The update bot tolerates and respects user changes. If a user finds a wrong stop, they should simply update or delete it rather than fiddle with the tag.
More about transport V2:
Two incremental updates were performed today. It appears 34 stops were updated by MOT in a single day.
Morning update - probably yesterday’s GTFS file: https://www.openstreetmap.org/changeset/53606095 (The numbers are misleading. Deletions include duplicate removals due to an earlier Overpass mistake that was fixed).
Evening update - today’s GTFS file: https://www.openstreetmap.org/changeset/53621985
The update had a minor positive unexpected effect on https://www.efobus.com/: When you scroll around their map, the markers need a few seconds to appear, but thanks to the synchronized blue square markers on the background map, you can see the position of the stops even before the click-able markers appear.
Here’s a visual map of osm-gtfs conflicts:
http://www.safwat.xyz/stops/ (rudimentary work in progress)
Hi
Thanks for a update.
I’ve found (really osmose found) duplicate stop here: http://www.openstreetmap.org/#map=18/30.01790/34.95113
Import bug or GTFS database has a glitch?
Thank you for the report. I’ve fixed this in changeset #55249140. 99 stop duplicates were removed.
This appears to be an upload issue and has happened before. It seems when JOSM fails an upload, things can get duplicated when I resume it. I’ll investigate this further.
Full list of duplicated stops:
Following this question on Facebook, how does one know when was the last Israeli gtfs import to OSM?
The import frequency is not clear from the Israeli Wiki.
The last bus stop update seems to be made 10 days ago.
You can follow the history of bus stop updates here:
https://www.openstreetmap.org/user/SafwatHalaby_bot/history
A log of all imports can be found here: https://wiki.openstreetmap.org/wiki/User:SafwatHalaby/scripts/gtfs#Changesets
The last import can be inferred from the log.
There is no defined frequency as of now. zstadler and I discussed this in private and we think the frequency should be well defined, and perhaps the entire import process should be automated. (It is currently semi-automated).
I think we can infer “Which stations does each bus route stop on” from the GTFS data. This should allow us to automatically maintain bus route relations (https://wiki.openstreetmap.org/wiki/Buses#Services) based on the GTFS data.
Let’s take Egged’s Route 480 as an example. That route is from Tel Aviv to Jerusalem (and back) with one intermediate stop. In routes.txt we have:
route_id,agency_id,route_short_name,route_long_name,route_desc,route_type,route_color
7020,3,480,מסוף 2000/עליה-תל אביב יפו<->תחנה מרכזית ירושלים/הורדה-ירושלים-1#,10480-1-#,3,
7022,3,480,מסוף רידינג-תל אביב יפו<->ממילא/קריב-ירושלים-1ק,10480-1-ק,3,9933FF
7023,3,480,תחנה מרכזית ירושלים קומה 3/רציפים-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-3#,10480-3-#,3,
7024,3,480,רמות/מסוף-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-31,10480-3-1,3,
7026,3,480,מסוף אגד/הרב פרדס-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-33,10480-3-3,3,
7027,3,480,כניסה ראשית/הדסה עין כרם-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-34,10480-3-4,3,
7028,3,480,מסוף אגד/קורן-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-35,10480-3-5,3,
7030,3,480,תחנה מרכזית ירושלים קומה 3/רציפים-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-3ד,10480-3-ד,3,
7033,3,480,מסוף אגד/צביה ויצחק-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-3ן,10480-3-ן,3,
7034,3,480,ממילא/קריב-ירושלים<->רדינג-תל אביב יפו-3ק,10480-3-ק,3,9933FF
10958,3,480,רב החובל/אדם-ירושלים<->מסוף ארלוזורוב/הורדה-תל אביב יפו-3ב,10480-3-ב,3,
15337,3,480,הראל/יסמין-מבשרת ציון<->מסוף ארלוזורוב/הורדה-תל אביב יפו-3ז,10480-3-ז,3,
which correspond to 8 variants. The primary variants are 7020 and 7023/7030, the other variants run once a day each (you can see the details on your favourite public transport app). All variants run under the same route number, 480 (third column).
We can then look up the route variant id, route_id=7020, in trips.txt where we find lines such as
route_id,service_id,trip_id,trip_headsign,direction_id,shape_id
7020,55452791,30445690_030318,ירושלים _ תחנה מרכזית,0,91509
and then we can look up the trip_id in stop_times.txt, which tells us what stops this route variant has (including the departure terminal, destination terminal, and all intermediate stops)
trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type,shape_dist_traveled
30445690_030318,18:12:00,18:12:00,41427,1,0,1,0
30445690_030318,18:48:08,18:48:08,41132,2,1,0,53910
30445690_030318,19:00:38,19:00:38,11734,3,1,0,62466
and now we look the stop_id up in stops.txt
stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,location_type,parent_station,zone_id
41427,20178,מסוף 2000/עליה, רחוב: עיר: תל אביב יפו רציף: 2 קומה: ,32.083251,34.795334,0,41391,5000
and 20178 is the ref=* value of the highway=bus_stop node! (See https://overpass-turbo.eu/s/vs1)
Bottom line: using this lookup process, we can build a type=route relation for every bus route variant and automatically maintain its role=stop members.
(That will allow OSM-based public transport routing apps to work in Israel)
Kudos to whomever got the ministry to release this information publicly under a permissive license. 
By the way, the CSV lines above appear to have misordered columns because of how Unicode infers text direction. If you actually parse them with split(‘,’) they would look right.