Import: Bus stops from GTFS

Regardless, I think that the note:name for “unlocked names” can be written in a more instructive form, such that a person who doesn’t know about your script who noticed a mismatch knows what to do.

name:ar and name:en are are possibly out of date. Translate them if you can. The bus stop names managed by a bot and usually shouldn't be modified, but you may modify them when this note is present, because they are lacking in the imported data.

(also, should I as a mapper remove this note if I translate?)

Perhaps it could. I’m not sold on your proposed language but we can workshop it.

Would you like to make a pull request? Relevant line of code: Making sure you're not a bot!

No. It’s an indication that the name isn’t imported from GTFS, which is still true even after it’s been updated by a human mapper. Keep this in mind when tweaking the note language - the not should still be correct after a human mapper changed the translated names.

If you delete the note, it will be re-added by the bot. If you edit the note, the bot will never touch the note again until it’s either removed or restored to the last value set by the bot. This is because the bot assumes notes added by other mappers are important and should never be removed or modified, and it makes no attempt to parse a note to figure out which parts are from itself and which parts are from other mappers.

I will see a log message about it in such cases so I can manually resolve it, so don’t be afraid to make whatever notes you want. The goal of the bot is to be as accommodating as possible for human mapping activity.

The note should be short and to the point. There is a hard limit of 255 characters, and I think we should stay well below that limit. Yours is less than 255, but only just.

I’ll give it a go:

name:ar and name:en could not be found in official imported data, and may be out of date or missing. You may update them as needed.

I think this is perfect. (Yes, mine wasn’t well thought out)

Hi, looking into latest changes by bot it may have problems with lines with א.
It puts א as separate entity with ;

Can you give an example? This may be a rendering issue on your end, what software are you using the view the route_ref value?

Yes, rendering - achavi - Augmented OSM Change Viewer  [attic] on Node: ‪City Terminal/Bet Hilel Boulevard‬ (‪5210696637‬) | OpenStreetMap
Look like Achavi bug.

1 Like

Ah. I’ve had it fixed in OSMCha and better-osm-org, but I forgot about achavi.

Edit: I will need to check JOSM too, just writing it here as a reminder to myself.

Reported to achavi: bidi (RTL) text in tags rendered incorrectly · Issue #58 · nrenner/achavi · GitHub

If I find a similar issue in JOSM I will report there as well and edit in a link to this post.

Edit: #24336 (Bidirectional text rendered inconsistently in input box) – JOSM ; RTL tags rendered incorrectly · Issue #773 · tyrasd/overpass-turbo · GitHub

Man I’m sick of this issue.

Sometimes I observe incorrectly positioned bus stops. Can I move them or will the position be reset on the next import?

1 Like

You can move them. Often the only reason they’re wrong is that someone else moved them accidentally. You can check by inspecting the node history.

If you move a stop very close to its GTFS position (within 5m IIRC) or add the tag restore:gtfs=position, then the GTFS position will be restored in the next update.

Please check out the wiki page, and feel free to ask if you have any more questions.

1 Like

Hi NeatNit!

Following you comment on Changeset: 177779284 | OpenStreetMap

The signs are definitely show HaCarmel. I would’ve paid attention if it was written incorrectly, as I happen to pass at that station from time to time.

I suggest that the title that comes from gtfs is set in en1 tag then the script leaves it as is.

What do you think?

Thanks, Danny

Take a look at these photos:

Imgur

Hi and welcome to the forum :slight_smile:

The bot currently only changes bus stops, not train stations, so any changes you made to the train station will remain. Still, I took a peek and it seems that for that train station, the GTFS data calls it “Hof Karmel Railway Station” so that’s annoying. But since the bot doesn’t touch train stations, that’s out of scope for this discussion.

What I need to see is the signage for the bus stops. I’m actually not sure they have it in the central station, because it’s all רציפים so they might not have the standard bus stop signs with the name.

Example bus stop as it appears in Moovit:

I might get a chance to go there this Sunday, but it’s a bit out of my way. We’ll see.

I do absolutely agree with you that they need to change all instances of “HaKarmel” to “HaCarmel”. It’s more pleasing and the consistency is needed. But that’s something to tell the ministry of transport, or perhaps the city council.

1 Like

As long as the railway station stays correctly - I’m happy.

1 Like

Regarding bus stops: The GTFS names are the ones that appear on the digital signs found on many bus stops, on navigation apps, and on the assistant/planner touch screens that are found on some central stations, so my view is that in a way the GTFS names are no less “ground truth” than the physical signs.

In my opinion, any discrepancy between bus stop signs in the field and the GTFS data is an error that needs to be reported upstream to MOT, so that they either update the data or the sign.

Since such discrepancy is rare for the bus stops and MOT does fix errors when reported, I think it’s not worth handling via more logic in the bot and the bot should simply follow the GTFS names for name:en/name:he/name:ar/name.

@NeatNit does the bot notify you when it overrides user-added names?

1 Like

Yup, for example:

2026-01-28 01:41:10,150 gtfs2osmCore [CRITICAL] A mapper tried changing name:en from 'Hof Karmel Railway Station' to 'Hof Carmel Railway Station' - does GTFS need correction? https://www.openstreetmap.org/node/1802982247/history/20

Relevant code: gtfs2osmCore.py

1 Like