Automated edits for name tags

It appears we have two different space characters in names.


\u00A0 - Unbreakable Space (NBSP)
\u0020 - Space (SP)

@wowik Many places have node, landuse=residential, and also an administrative boundary from the MOIN import. So that’s 3 places per … place.

Please note that massive updates are causing delays in the updates of the Israel Hiking and Biking maps.
Since 2-June it takes more than 36 hours to complete the maps updates, compared to 1-4 hours previously.

Also see https://www.facebook.com/groups/994960670559126/permalink/1360244540697402/

Thanks for notifying me!

  1. 99%+ of the changes were name to name:he copies. This should be a one-time load.

  2. I updated 5 of the 7 Israel districts in one week. I could have spread this over weeks had I considered the load. I will update the remaining 2 districts in 1 week intervals or more, and will pause the updates for now until things propagate properly.

  3. I am glad you reported this now. I was about to run it for the remaining districts.

I halted my changes for now, but is IHM down? And is it related?

https://www.facebook.com/groups/994960670559126/permalink/1364330870288769/

Would this algorithm addition be acceptable?

  • If name and name:he mismatch (and they’re both Hebrew), see which one was the most recently updated, and update the other one accordingly.

Strongly against it - I found many streets where last edit was problematic. When you do automatic edit over problematic one it make very hard to spot an error and make harder to find the source of error.

I accidentally pushed an experiment. Will revert in a second.

Reverted. Further explanation: The autofix code has been ready for a while, but didn’t work due to a bug in the scripting plugin. Today, that bug was fixed, and I went ahead and tested the code, but I also accidentally uploaded.

Now that it works, we need to decide if it’s desired.

I believe the benefits are greater than the drawbacks, but I am willing to stand corrected. Here is why:

  • Most people make good edits (I hope!), if so, the the last edit should usually be correct. We need to check out the diff to confirm this: #50233725 (which is now reverted)

  • Name/name:lang mismatch are very hard to manually detect because sometimes it’s the good name that renders or shows up in editor descriptions. Because of that, sometimes these mistakes survive for months or even years. Example here. I argue it’s often easier to see the bad edit when it appears in both tags. Quite often, a name mismatch can only be detected by someone actively looking for mismatches.

  • When I find a mismatch, I often trace the history to figure out which name is newer. That’s mechanical and boring, and the bot can do it for me, faster.

  • I want the bot to “simulate” a single name tag. When you edit one tag, you are forced to edit the other whether it’s a good or a bad edit. I believe this makes life easier.

We could have a middle-ground, where we manually review the autofix. (I can post them here whenever they’re made), It’s still much faster than manual fixes, and will also catch the bad edits.

how about a: fixme=“Name fixed by bot. Please review.”?

I don’t think the “fixme” tagging is working. There are more than 30,000 nodes and 1700 ways with a “fixme” tag in Israel, not no mention “fixme” in “note” tags…

Having an table with columns for “name”, “name:he”, “name1”, and “name:he1” would be more efficient.

See this post for how to update OSM tags using a CSV file.

I’d say fixmes pending review indefinitely are better than name mismatches pending review indefinitely.

By the way, almost all node fixmes are from the GTFS bus stop import. It may be wise to bulk-remove those, to shine the light on the more important fixmes.

Edit: Sorry, I was confusing this with something else and this comment is wrong regarding overpass. Please ignore the previous version of this comment.

I’ll not apply auto-fixes for now. I’ll look into manually updating them (via the csv method or some other way).

Nope, I still don’t like this. It’s wasted manpower; Even if I manually fix them all, the mismatches will accumulate over time and the manual fix must be done periodically, and most mismatch “errors” will be in fact legitimate edits where someone changes a name tag and forgets the other. It’s mechanical drudgery.

Wouldn’t it be easier to just treat the two tags as a single tag and have the bot auto-synchronize them? We also don’t even need a fixme for this; If a user mis-edits a tag, it’s not the synchronization’s fault. Mis-edits are normal in OSM, and name tag mis-edits should be handled like any other mis-edit, through monitoring tools and such.

I can understand the need for a fixme tag for the first edit only (because some autofixes will be grabbed from deeper history), but no need for a fixme when this is synchronized periodically. By the way, it’ll only add an additional 372 fixmes to the 30k already present.

For the record, http://overpass-turbo.eu/s/qmy is a query that finds elements in Israel that have a Hebrew “name” tag and a “name:he” tag that are different.

It has an option to output a CSV file by un-commenting the CSV output definition.

The current element count is: nodes: 62, ways: 430, relations: 11

There are also 586 in total, if we count Arabic, Hebrew, English. 372 of which are auto-fixable by swiftfast_bot.

Does everyone agree that we should always have Hebrew “name” tags duplicated at “name:he”? I asked prior to running the scripts and I think everyone agreed, but I cannot find the post anymore. (Rationale: The language of the “name” tag varies in Israel. But name:he guarantees Hebrew).

I agree that

The following cases should not be handles automatically:

  • name tags with foreign language characters
  • name tags that are different than the name:he tags

The current rules are similar, except for line 2. I think they are as follows.

This allows copying things like “KSP מחשבים”. Do you think that’s a bad idea?

I should publish the source code soon. (I wanted to fully automate it first, but that’s not going to happen soon).