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