PTNA checks this while analyzing a route relation. If ‘route_ref’ exists on a stop, ‘ref’ of the relation must be listed there. If ‘route_ref’ does not exist, nothing happens. It is widely used in my area.
Do you mean by this that if a relation’s ref is missing from a stop’s route_ref, then this is listed as an error for the route in the analysis page? Or something else happens?
If it’s what I said, this sounds useful for detecting outdated route relations, of which there are plenty. Occasionally gtfs2osm wants to delete a bus stop, but fails because it’s part of a route relation that hasn’t been updated in ages, and I have to fix it manually.
Correct. If route_ref exists it must be exhaustive and correct.
PTNA is in the comfortable position of only checking whether ref is in route_ref, that’s all.
gtfs2osm has the more complicated task of proposing the value of route_ref, right?
Yes, but it’s not that hard. Python makes tasks like this almost trivial. It’s a little bit harder if I want to maintain the order set by other mappers, as route_ref should ideally list the lines in order of importance. But even that should be easy enough for me.
@NeatNit
לא הבנתי למה לא להעתיק גם את מספרי התחנה שבתוך הרציפים?
הרי גם אלה נתונים מתוך קובץ התחנות ב
GTFS
כדי שכל הקוראים יבינו על מה אנחנו מדברים:
אתה הוספת את הרציפים בתחנה המרכזית באילת: Changeset: 163660825 | OpenStreetMap
שזה כמובן דבר טוב ומוערך! יש רק שתי בעיות:
- הייבוא שלי לא ממש יודע איך להתמודד עם זה. במיוחד הייבוא לא מצפה שמשתמשים אחרים יוסיפו תגיות gtfs:*:IL-MOT, שאתה הוספת.
- השתמשת בתגית ref בשביל מספר הרציף, כשלמעשה אמורים להשתמש ב-local_ref.
אז אני הצעתי שלעת עתה נמחק את התגיות gtfs ואת ref - כדי לא לבלבל את הייבוא - ונשאיר במקומם את local_ref ואת שאר התגיות (שם וכו׳). אז זה לא יתנגש עם הייבוא. ואני אנסה בהזדמנות הראשונה לשפר את הקוד שלי כדי שיוכל להתמודד כמו שצריך עם רציפים שונים של תחנה מרכזית, ולאחר מכן נוכל להחזיר את התגיות האחרות.
לצערי הכמה שבועות הקרובים הם מאוד עמוסים בחיים שלי, ואני לא חושב שאוכל למצוא את הזמן להתעסק בזה.
Edit: for reference, this is the open issue regarding central stations, which I will now consider high priority: #5 - Figure out how to do central stations - NeatNit/gtfs2osm-il - Codeberg.org
@SafwatHalaby, today is the first time (AFAIK) that a newly imported bus stop uses an Arabic name: Node: Haifa Road/5124 (12681493279) | OpenStreetMap
It’s in Nazareth. Seems to be working as it should so far 
Awesome! Looks like a healthy baby bus stop to me!
I’m putting imports on hold as I work on fixing some open issues with gtfs2osm. Might still run it every now and again but not every day like I used to. Daily updates will resume once the biggest issues have been solved.
I also might change the project’s name, to a name that isn’t already taken by various other projects when searched online 
Just ran the import again after making the code more robust and less prone to making unwanted edits when other mappers have made a mess. In such cases it will leave the existing stops as they are and alert me of the errors.
Examples of errors:
- Multiple stops with the same ref (note: this will not be an error after central stations are implemented)
- Mismatch between
refandgtfs:stop_code:IL-MOTvalues gtfs:stop_id:IL-MOTexists in GTFS but associated with a differentstop_code
In all of those cases, the script will avoid making changes or creating new stops for anything that shares the same stop_id or stop_code/ref.
I will resume daily (ish) updates from now on!
Because the script didn’t run for 2 weeks, a lot of changes have accumulated. Please review if you can: OSMCha / achavi - Augmented OSM Change Viewer [attic] / Changeset: 165210643 | OpenStreetMap (I will look through it as much as I can but I can’t examine every change)
In particular, it seems that most of the stops in Nazareth have had their name changed. Side note: name language now defaults to Arabic in Nazareth: Node History: al-Batris/Salesian (1803095537) | OpenStreetMap 
This seems to indicate that a lot of streets have been renamed in this city. Does anyone know anything about this? Do we need a mapping party to rename all streets in this city? (I feel out of my area of comfort so I won’t be looking into this further for now, hope others can handle it…)
Near-future plans:
- Add
route_refas previously discussed (#20) - Finally add support for central stations and their separate platforms (#5) - all would share the same
refbut have a uniquelocal_ref. Positioning each platform will need to be done manually - GTFS has the same coordinates for all platforms. - Start accepting a bit of statefulness in order to create newly-built stops even before they serve actual routes (#44)
I randomly sampled about 10 stops.
In the sample, most changes were semantic, involving: transliteration changes, swapping the name on the left with the name on the right for buses on intersections, translating slightly differently, or changing a name to a similar name (e.g. המעיין becomes מעיין מריים).
Sometimes, streets that were numbers became names.
- n1803067402: המעיין/פאולוס השישי became פאולוס השישי/מעיין מרים
- n1803017659: A slightly more accurate transliteration, but the slash and the other street name was removed.
- n7941722728: בית חולים איטלקי 5 became נמסאוי/ביטוח לאומי
- n1803093232: ميناحيم أرياڤ becameمناحم أرياڤ . A slightly different transliteration, might be slightly better.
- n1803017684: هچليل/حي الروم became طريق الجليل/الروم - semantic change. Left and right sides were flipped. “Neighborhood of Romans” became “Romans”, “Galil” became “derekh Hagalil”.
- n1803095537: A street number became a street name.
I think some streets got a new name (they were a number), but most are actually unchanged.
Thanks for the review.
Those streets that used to be numbers are the most interesting to me. The other changes, if the bus stop name change actually reflects a street name change (even if it’s minor), is still actionable.
Any idea where to find info about this? I might have tried reading through recent protocols, but they’re only in Arabic: https://www.nazareth.muni.il/arabic/info/Pages/protocols.aspx (plus I just noticed most recent is from 2023, clearly not new enough)
Started work on this. Encountered a problem I didn’t think about - some bus stops have a ludicrous number of routes stopping at them. The worst offender is stop 21472 Azrieli Mall/Menahem Begin Road, where 110 different route numbers stop, resulting in a route_ref string that is 423 characters long. The maximum tag length on OSM is 255.
Not really sure if there’s a good solution in such cases. I’ll probably leave the route_ref field unset and add note:route_ref=Too many routes: 110 routes making 423 characters for route_ref
The route_ref tag has now been added to all bus stops:
Changeset: 165483160 | OpenStreetMap (north)
Changeset: 165483169 | OpenStreetMap (center)
Changeset: 165483183 | OpenStreetMap (south)
Note that only bus routes (route_type=3) are added. Other kinds of routes listed in GTFS are ignored.
These stops have too many routes to be tagged: Overpass Turbo: node[“gtfs:stop_id:IL-MOT”][“note:route_ref”];
These stops don’t serve any bus routes, and might not exist in reality and need to be removed: Overpass Turbo: node[“gtfs:stop_id:IL-MOT”][!route_ref][!“note:route_ref”];
I’m incredibly pleased with how fast this was. The last time I had to update all ~30,000 bus stops, it took like 3 hours because I wasn’t using the batch upload API - each element was updated in a separate API call. I have since implemented the batch API, but never made a change that affected all (or nearly all) bus stops at once, so I never gave it a proper test run - until now!
The first changeset was created at 00:19:30, and the final changeset was closed at 00:20:17. It took less than a minute to update nearly 30,000 nodes. Hooray!
This also shows off the ordering of changes from north to south, which almost never comes into effect 
1 Like
Not too surprising, but it seems like route_ref gets updated at a much faster pace than any of the other tags updated by gtfs2osm:
2025-04-27: 17 changes
2025-04-29: 78 changes (and 20 Hebrew name updates, ~40 English/Arabic name updates)
2025-04-30: 36 changes (and 52 Arabic name updates)
2025-05-01: 102 changes (and 2 Hebrew name updates)
2025-05-02: 23 changes
I don’t think it’s getting out of hand per se, but it does kind of feel like adding noise to the database. I haven’t tried analyzing if route changes get applied to the same stop multiple days in a row - e.g. removed one day and added back the next.
To be clear - the list is generated from all routes stopping at each stop in the GTFS data, which should include all trips for the next 30 days. I would have expected this list to remain stable day to day (and indeed, for the vast majority of bus stops, it does remain stable). These frequent changes are not related to the weekly scheduling of trips.
I still think this data is useful enough that the “update noise” is worth it, but figured I’d be transparent about it.
Here’s an interesting stop.
- It had
name:ar,name:en, andname:hein GTFS data name:hewas updated upstream, andname:ar,name:enwere removed.- The bot updated
name:hebut did not removename:arandname:enfrom OSM. - A user opened a note regarding an error.
Is this intended behavior?
I think you’ve figure out the answer - your last reply on that note is correct. The note:name tag indicates when the English/Arabic names are “unlocked” and can be freely edited.
This behavior is exactly what we agreed on some months ago, is it not?
You’re right. This is exactly what we agreed on and I missed this. But this makes me think it can be refined slightly.
I am wondering if this is even worth thinking about, since it’s so uncommon.
But let me think about it for a while, maybe there’s some low-hanging fruit and a minor refinement…
Unfortunately it’s not so uncommon. Lots of stops get their Hebrew name changed and it takes a while for the MOT to update the English and Arabic translations to match - in the mean time, they’re just totally absent from GTFS. There’s clearly an upstream issue in the policy/process for updating stops data, but that’s what we have to deal with.
It’s easy to find current stops with this issue, right now there are 20: node["gtfs:stop_id:IL-MOT"]["note:name"];out;
What’s better, a temporarily stale name:ar/name:en or a temporarily deleted one? I think the latter can be done relatively cleanly if we determine it’s a better approach.
But, 20 stops with temporarily stale secondary names isn’t so bad at all.