Proposal: review nonstandard name:en1/name:en2 keys related to this community

Communities ישראל (Israel)
1

I would like community feedback on a proposed review of numbered English-name
tags such as name:en1, name:en2, name:en3, etc. in the main affected
OSM bbox around this community

This proposal is about changing nonstandard key structure while preserving the
name information. It is not a proposal to remove Hebrew, Arabic, English, or
other names from objects. It is also not a proposal to choose or standardize
English spellings.

The Israel forum appears to be the best primary venue because this tag family
is mostly local to this community’s historical workflows.

Process references:

Summary

Many objects in and around Israel currently use tags like these:

name:en=Yavneel
name:en1=Kefar Yamma
name:en2=Yabneel
name:en3=Yabniel
name:en4=Yamah
name:en5=Yamma
name:en6=Yavniel

The numbered keys are not standard OSM language-name keys. Standard
language-specific names use name:<language-code>, for example name:en.
en1, en2, etc. are not language codes.

Most of these numbered values appear to be alternate Latin-script or English
transliterations. For that case, the normal OSM tagging target is
alt_name:en, using semicolons when there are multiple alternate names.

The example above would become:

name:en=Yavneel
alt_name:en=Kefar Yamma;Yabneel;Yabniel;Yamah;Yamma;Yavniel

The proposal is to handle these numbered tags in stages, starting with the
lowest-risk duplicate cases and discussing any wider migration before upload.

Scope

The proposed scope is the main affected area:

south=29.3
west=34.2
north=33.5
east=35.9

This bbox contains almost all current global uses of exact name:en[0-9]+
keys.

Current counts checked against Taginfo and Overpass:

Taginfo data timestamp:              2026-05-11T00:59:45Z
Overpass checks:                     2026-05-12
Global exact name:en[0-9]+ tags: 81,624
Tags inside the proposed bbox:      81,280
Share inside proposed bbox:         about 99.58%
Affected objects inside bbox:       46,813

The high-volume keys are:

name:en1   45,869 globally
name:en2   19,494 globally
name:en3    9,353 globally
name:en4    4,645 globally
name:en5    1,588 globally
name:en6      596 globally

There are small numbers of name:en7 through name:en14.

I am not proposing to include the remaining small number of objects outside
this bbox in the first edit, because they may have different local context.

Background

The numbered keys appear to have two main origins.

First, some place-name objects appear to have received variants from GNS
data, for example objects with source=GEOnet Names Server (gns).

Second, a local Israel street-name cleanup workflow used spreadsheets and bulk
editing around 2012-2015. Older forum discussions explicitly mention columns
like name:en, name:en1, name:en2, etc. as a way to keep multiple
searchable street-name variants.

Relevant older discussion:

So these tags should not be treated as random junk. They contain useful names.
The problem is the key format, not the values themselves.

Why Change This?

name:en1, name:en2, etc. are not documented OSM language-name keys and
are not valid name:<language-code> keys.

The usual tagging model is:

name:en=main English name
alt_name:en=alternate English names
old_name:en=historical English name
official_name:en=official English name, if different from common name
short_name:en=short English name

For multiple alternate names, semicolon-separated alt_name:en is the
documented pattern:

alt_name:en=Name One;Name Two;Name Three

Moving existing alternate transliterations from numbered name:enN keys to
alt_name:en would make the data easier for mappers and data consumers to
understand without losing the alternate names. It would not invent new
translations or choose between competing spellings.

Relevant tagging guidance:

  • OSM Wiki, multilingual names
  • OSM Wiki, name key
  • Israel naming guidelines

Value Length Limit

OSM tag keys and values have a maximum length. The OSM API v0.6 documentation
says each tag key and value can be up to 255 Unicode codepoints, not bytes.

This matters because the proposal may combine several numbered values into one
semicolon-separated alt_name:en value. I checked the current affected bbox
against this limit.

Result:

OSM base timestamp checked:                         2026-05-12T17:28:14Z
Existing numbered values over 255 codepoints:       0
Existing alt_name:en values over 255 codepoints:    0
Merged alt_name:en values over 255 codepoints:      0
Longest current numbered value:                     71 codepoints
Longest existing alt_name:en value:                 105 codepoints
Longest proposed merged alt_name:en value:          127 codepoints

So the proposed migration is not currently blocked by value length. The edit
tool should still check the final alt_name:en value before upload and skip
or send to human review any object where the result would exceed 255 Unicode
codepoints.

Consumer Checks

The main current consumer found for the numbered keys is Nominatim.

Nominatim currently indexes broad name:* keys, which means it can pick up
nonstandard keys like name:en1. Nominatim also indexes alt_name:* and its
tokenizer splits semicolon-separated name lists. Public Nominatim tests
confirmed that semicolon-separated alt_name:en values are searchable.

Examples checked:

alt_name:en=Elath;Elat;Ilat
search "Ilat Israel" finds Eilat

alt_name:en=Athlit;Athlith
search "Athlith Israel" finds Atlit

alt_name:en=Al Qubeiba;El Qubeiba;El Qubeibe;Kafr Hanagid;Qubayba;Qubaybah;Qubeiba
search "Qubaybah Israel" finds Kfar HaNagid

Other checked consumers did not show a confirmed user-facing benefit from the
current name:enN format that would be lost by moving to alt_name:en.

Pelias, Photon, and Organic Maps source checks did not show support for
name:en1 as a valid English-name key. OsmAnd was tested with a small
generated .obf; address/street search did not find a synthetic street by
name:en1, and also did not find it by alt_name:en. That means OsmAnd may
still need separate improvement for alt_name:en, but the test did not show
that current name:en1 is preserving OsmAnd street search today.

Proposed Stages

Stage 1: Low-Risk Duplicate Removal

Remove numbered tags only when the value is already preserved on the object.

Rule 1:

if name:en1 == name:en
remove name:en1

The same applies to name:en2, name:en3, etc.

Rule 2:

if name:enN is already present as an exact semicolon-separated value in alt_name:en
remove name:enN

Confirmed low-risk duplicate-removal scope inside the bbox:

Exact duplicates of name:en:                 3,401 tags
Already present in alt_name:en:                  4 tags
Total low-risk removable numbered tags:      3,405 tags

This is about 4.19% of numbered English-name tags in the bbox.

I think this stage is suitable for a small mechanical edit if the local
community agrees.

Stage 2: Review or Approved Migration to alt_name:en

For objects where name:enN contains a distinct alternate English name or
transliteration, migrate the values into alt_name:en and remove the numbered
keys.

The rule would be:

  1. Keep name:en unchanged.
  2. Read existing alt_name:en, if present.
  3. Split existing alt_name:en on semicolons.
  4. Read name:en1, name:en2, …, name:en14 in numeric order.
  5. Skip empty values.
  6. Skip values that exactly equal name:en.
  7. Skip values already present in alt_name:en.
  8. Append remaining values to alt_name:en in numeric order.
  9. Check that the final alt_name:en value is no more than 255 Unicode
    codepoints.
  10. Remove the numbered name:enN keys.

Example:

before:
name:en=Nahariyya
name:en1=Nahariya
name:en2=Naharija
name:en3=Naariya

after:
name:en=Nahariyya
alt_name:en=Nahariya;Naharija;Naariya

Example with existing alt_name:en:

before:
name:en=Shefa-Amr
alt_name:en=Shefaram;Shfaram;Shefa-'Amr
name:en1=Shafa Amr

after:
name:en=Shefa-Amr
alt_name:en=Shefaram;Shfaram;Shefa-'Amr;Shafa Amr

If this full migration were applied inside the bbox, the estimated effect
would be:

Objects with at least one numbered English-name key: 46,813
Numbered name:enN tags removed:                    81,280
Objects where alt_name:en would be created:        44,319
Objects where alt_name:en would be updated:           108
Distinct values added to alt_name:en:              76,873
Net tag-count reduction:                           36,961

This stage is large enough that I do not think it should be uploaded without
explicit local community agreement. If people prefer, it could instead be
published first as a QA task for human review.

Cases to Skip or Send to Human Review

The proposed edit should skip or require human review for cases where:

  • there is no name:en;
  • the numbered value looks historical and may belong in old_name:en;
  • the numbered value looks official and may belong in official_name:en;
  • the numbered value is an abbreviation and may belong in short_name:en;
  • the object is a GNS-derived place-name object where the variant may not be a
    simple alternate transliteration;
  • the value is not actually English or Latin-script;
  • the object has recent dispute or complicated multilingual naming history;
  • the proposed final alt_name:en value would exceed 255 Unicode codepoints;
  • the value differs only by punctuation, casing, or whitespace, unless that
    normalization rule is separately discussed.

The first mechanical edit, if any, should probably only handle exact
duplicates. The broader migration can be reviewed separately.

What Would Not Change

The edit would not change:

  • name;
  • name:en;
  • name:he;
  • name:ar;
  • route, address, or highway tags;
  • the mapped geometry;
  • the actual name strings, except for moving them from numbered keys into
    alt_name:en.

The intended result is preservation of alternate names in standard OSM tags,
not removal of names.

Changeset Plan

If the community agrees to a mechanical edit, I propose:

  • small geographically scoped changesets;
  • changeset comment such as:
Review numbered English-name keys: remove duplicates or migrate agreed variants
  • changeset tags including:
mechanical=yes
bot=no
discussion=<forum topic URL>
  • upload only after a published before/after sample has been reviewed;
  • keep a machine-readable before/after log for rollback;
  • stop immediately if local mappers report a problem.

This would follow the OSM automated edits code of conduct.

Questions for the Community

  1. Is the local community comfortable with removing exact duplicate
    name:enN tags where the value already equals name:en or is already in
    alt_name:en?
  2. For distinct alternate transliterations, should these be migrated to
    alt_name:en, or should they first be presented as a QA task for manual
    review?
  3. Are there known local tools, apps, QA workflows, or data consumers that
    currently depend on name:en1, name:en2, etc. specifically?
  4. Are there object classes that should be excluded from any mechanical edit,
    especially GNS-derived place nodes?
  5. Is alt_name:en the right target for these alternate Latin-script
    transliterations, or should some subset use a more specific key such as
    old_name:en, official_name:en, or short_name:en?

Notes on the Evidence

The counts above were checked directly against Taginfo and Overpass. The
history examples and old discussions are linked in the relevant sections above.

The main Overpass query pattern was:

[out:json][timeout:180];
(
  nwr["name:en1"](29.3,34.2,33.5,35.9);
  nwr["name:en2"](29.3,34.2,33.5,35.9);
  nwr["name:en3"](29.3,34.2,33.5,35.9);
  nwr["name:en4"](29.3,34.2,33.5,35.9);
  nwr["name:en5"](29.3,34.2,33.5,35.9);
  nwr["name:en6"](29.3,34.2,33.5,35.9);
  nwr["name:en7"](29.3,34.2,33.5,35.9);
  nwr["name:en8"](29.3,34.2,33.5,35.9);
  nwr["name:en9"](29.3,34.2,33.5,35.9);
  nwr["name:en10"](29.3,34.2,33.5,35.9);
  nwr["name:en11"](29.3,34.2,33.5,35.9);
  nwr["name:en12"](29.3,34.2,33.5,35.9);
  nwr["name:en13"](29.3,34.2,33.5,35.9);
  nwr["name:en14"](29.3,34.2,33.5,35.9);
);
out tags meta;

Counting method:

  • Count every exact key matching ^name:en[0-9]+$ as one numbered tag.
  • Count each OSM object once for the affected-object total, even if it has
    multiple numbered keys.
  • For duplicate removal, compare each numbered value exactly against
    name:en.
  • For the existing alt_name:en check, split alt_name:en on semicolons,
    trim surrounding whitespace, and compare exact values.
  • For the hypothetical migration count, preserve existing alt_name:en
    values first, then append missing numbered values in numeric order.
2

I will mostly be watching this from the sidelines, as I don’t have anything to weigh in. I agree that the nonstandard tag use is a bad idea. But I will just note that more instances can be found with a more general Overpass query:

[out:json][timeout:180][bbox:29.3,34.2,33.5,35.9];
nwr[~":[a-z][a-z][0-9]+"~".*"];
out count;

This catches tags like:
old_name:en1
mtb:name:en1
old_name:he1

Perhaps you left them out on purpose, but if not, here they are.

Edit: changed query from en to [a-z][a-z]

3

I’ll be honest, I didn’t check those paths, but if they exist I would likely consider them to be part of this proposal as well.

4

I generally think this is a good direction.

I was going to mention name:heN as well as something worth looking into as part of this effort.

5

I’m happy to add name:heN to the scope of this review, though I’ll note that I don’t speak the language so will only be doing string comparisons.

6

I’ll note that I don’t have access to Telegram, so would appreciate someone raising awareness of this topic there if they feel it would be useful.

My current plan is, if no objections are raised between now and then, on Tuesday 19 May 2026 I will post random samples of the proposed stage 1 changes. If nobody objects to those samples, I will proceed to make the changes 24 hours later.

Stage 2 will follow a similar timeline starting from Tuesday 26 May 2026, again assuming no issues are raised between now and then. This will allow time for stage 1 changes to soak and for anyone to notice and raise issues.

7

does anybody knows level of adoption of semicolon separated entries in popular services like Nominatim?

8

Nominatim indexes alt_name:* and its
tokenizer splits semicolon-separated name lists. Public Nominatim tests
confirmed that semicolon-separated alt_name:en values are searchable.

Examples checked:

alt_name:en=Elath;Elat;Ilat
search “Ilat Israel” finds Eilat

alt_name:en=Athlit;Athlith
search “Athlith Israel” finds Atlit

alt_name:en=Al Qubeiba;El Qubeiba;El Qubeibe;Kafr Hanagid;Qubayba;Qubaybah;Qubeiba
search “Qubaybah Israel” finds Kfar HaNagid

1 Like
9

Great initiative!

It’s worth noting that the number of “alternative names” often explodes because of transliteration combinatorics. If some letter can be transliterated as either “C” or “K”, and some word can be tranlisterated as “al” or “el”, suddenly you have 4 ways of transliterating the same word. Add a few more degrees of freedom you get the monster that is n278476860.

I would say this is far from ideal and in a perfect world should be resolved elsewhere in the stack.

I think the reason people felt compelled to push all of the these combinations is mainly poor search engine heuristics, especially for non latin languages. So it’s some sort of tagging-for-the-search-engine. In a world where only ONE form of transliteration is used in OSM for each actual alt_name, you’d find far, far less alt names in the wild.

Taming the alt_name and adhering to the character limits might require some policy regarding transliteration combinatorics.

1 Like
10

@TaggingReviewer may I ask, who are you and why did you create a new account for this thread? Seems like a strange choice for an otherwise very sensible proposal.

2 Likes
11

totally agree, no reason to keep duplicates.

don’t know any

I’m not sure it’s correct to move name:xxn to alt_name. I’d expect alt_name to have a very different content and not just a different transliteration or spelling of the name. So I’d only merge value of the same numbered tags into single tag without changing the tag itself.

12

I actually think alt_name fits perfectly. Key:alt_name - OpenStreetMap Wiki

This tag can be used when a […] feature has another common name but there is some other alternative form.

[…]

It can be used when has several alternative orthographies (possibly in other scripts) and even the orthography of the preferred name is uncertain.

[…]

Examples

Multiple alternative names

Use a semicolon to separate multiple values:

  • name=Jomotsangkha and alt_name=Jomotshangkha;Jomot Shangha;Jomot Sangkha;Jomotshangka

All mentions of alt_name in Key:name - OpenStreetMap Wiki also agree with this usage, especially this example:

name=Field Fare Road and alt_name=Fieldfare Road

1 Like
13

Thank you!

For what it’s worth, I investigated the max size limit, which is 255 unicode characters. The longest entry from this proposal after all stages are complete would be 127 unicode characters, well below the limit. I acknowledge that this might be kicking the can down the road, but for now it seems reasonably safe to do so.

Way to be changed: Way: ‪Sails Square‬ (‪189600365‬) | OpenStreetMap

alt_name:en = Kikar HaMifrashiot;HaMifrasim Square;Kikar HaMifrasim;HaMifrasim Roundabout;The Square of Sails;Kehilat Yots’ei Saloniki Square
1 Like
14

The answer is pretty simple: I’m brand new to the community :slight_smile: I haven’t been involved in OSM work before, but have recently been building a private tool that includes strict validation of mapping output vs the OMT schema, and I took that to mean name:[a-z][a-z] only, so the validation showed up the name:en[0-9]+. And then my brain which loves standards latched onto that as something to look into.

I don’t even think the ones that flagged were from this region - it’s just when I investigated it the vast majority were here.

2 Likes
15

Thank you for your input! On this note, on top of what @NeatNit said, I’ve pulled together some examples of other locations where this is the way that it’s done:

Region Object Native/current name Main English name alt_name:en
Thailand way 25620825 ถนนศรีนครินทร์ Srinagarindra Road Si Nakharin Road;Sinakharin Road;Srinakarin Road;Sinakarin Road
Thailand way 42505008 ถนนห้วยแก้ว Huaykaew Road Huai Kaew Road;Huay Kaew Road
Thailand node 248907803 บ้านบ่อสร้าง Ban Bosang Ban Bo Sang;Bo Sang;Bor Sang;Borsang
Thailand way 28151683 ถนนบูรณศาสตร์ Burana Sat Road Thanon Buranasat;Thanon Burana Sat
Thailand way 32039604 ถนนจารุเมือง Charu Mueang Road Thanon Charu Mueang;Charumueang Road
Taiwan way 231112989 中正路 Zhongzheng Road Chungcheng Road;Jhongjheng Road
Taiwan way 215580963 中正東路 Zhongzheng East Road Chungcheng East Road;Jhongjheng East Road;Jungjeng East Road
Taiwan way 243288005 中環路一段 Section 1, Zhonghuan Road Zhonghuan Road Section 1;Section 1, Chunghwan Road;Section 1, Jhonghuan Road
Taiwan way 233578974 中華路 Zhonghua Road Jhonghua Road;Chunghwa Road
Taiwan way 106763874 新莊路 Xinzhuang Road Hsinchuang Road;Sinjhuang Road
Taiwan way 250500735 中山路 Zhongshan Road Chungshan Road;Jhongshan Road;Jungshan Road
Taiwan way 128357406 瑞慶路 Ruiqing Road Ruiqing Road;Rueicing Road;Juiching Road
Taiwan way 367600040 中和路 Zhonghe Road Jhonghe Road;Chungho Road
Taiwan way 25715400 青島東路 Qingdao East Road Tsingtao East Road;Chingdao East Road
Taiwan way 231702808 新泰路 Xintai Road Sintai Road;Hsintai Road
China/Tibet way 258572767 麻嘎藏布 Maga Zangbo Maka Zangbo;Maga tsangpo;Magazangbu;Makazangbu He
China/Tibet way 829942377 拉巴藏布 Lawar Zangbo Labar Zangbo;Lawar tsangpo;Labar tsangpo;Labazangbu
China/Tibet way 222928732 纳雄藏布 Ro'gyog Zangbo Ru'gyog Zangbo;Rokyok tsangpo;Rukyok tsangpo
China/Tibet node 244081302 尼木县 Nyemo Nimu County;Ni-mu Hsien;Nyemo;Nyemo County;Nimu
Central Asia node 1587454442 Эски-Гульбаг Eski-Gulbag Dzhamatuy;Dzhamashuy;Jomashuy;Dzhumashuy
Central Asia node 1511286775 Даxбет Dahbet Dakhbed;Dagbit;Dagbid;Dakhbet
Georgia way 153932266 ფირდოუსის ქუჩა Ferdowsi Street Pirdousi Street;Firdous Street

Hopefully this helps!

2 Likes
16

I understand why @yrtimiD is feeling weird about alt_name containing so many variants of the same transliteration. The root cause is the combination problem I mentioned before. In an ideal world only one transliteration variant per actual alt name is added (or a few commonly used ones). But I think this proposal is a big improvement on the existing state even if it doesn’t take us to the ideal yet.

By the way, back when I tried standardizing names (or more precisely, mostly writing down what the IL community already knew intuitively), I considered standardizing transliteration too (e.g. always use al rather than el in Arabic-to-En transliteration) but I concluded it’s a can of worms that requires far more effort than I am willing to invest and wouldn’t even solve the problem on its own. The prerequisite to reducing the alts is making sure downstream tech (like search engines) is good at fuzzy searching whether it’s a Latin, Hebrew, or Arabic alphabet. This might entail some code submissions…

17

I did a little investigation on this. Turns out Nominatum already has something like this through their token analyzers.

See: here and here. Notably it currently has support for:

bg Bulgarian, ca Catalan, cs Czech, da Danish, de German, el Greek, en English, es Spanish, et Estonian, eu Basque, fi Finnish, fr French, gl Galician, hu Hungarian, it Italian, ja Japanese, mg Malagasy, ms Malay, nl Dutch, no
Norwegian, pl Polish, pt Portuguese, ro Romanian, ru Russian, sk Slovak, sl Slovenian, sv Swedish, tr Turkish, uk Ukrainian, and vi Vietnamese.

Not currently included: he Hebrew or ar Arabic.

Source: Nominatim default settings/icu_tokenizer.yaml.

Might be worth someone putting their mind to it - it might not be as difficult as expected.

Anyway, that will be a separate problem for another day, I think!

18

Kind-of relevant new proposal, but I don’t think it should change anything discussed in this topic: Proposal:*:language-Latn for name keys around the world - OpenStreetMap Wiki

19

Stage 1 notice: remove duplicate numbered language tags in the affected bbox

I plan to submit Stage 1 of the numbered language tag cleanup no sooner than 24 hours after this post, unless there are objections or specific cases that need to be excluded. I’ve expanded it to include all language# variants (e.g. name:he1, name:ru1) in the bbox, based on the feedback here. Additionally, I’ve added alt_name:en1 (and other such variants) to this, where they would be rolled back into semi-colon separated lists in their parent tag (e.g. alt_name:en1 would get added to alt_name:en)

This is only the conservative duplicate-removal stage. It does not do the larger migration of alternate names into alt_name:*; that would be a separate later stage after more review.

Scope

The current working bbox is:

(29.3,34.2,33.5,35.9)

The query used for the source snapshot matches numbered language-suffix keys:

^.+:[A-Za-z]{2,3}[0-9]+$

This includes examples such as name:en1, name:he1, old_name:en1, and similar small numbered-language variants in the bbox.

What Stage 1 will change

Stage 1 removes a numbered tag only when its value is already preserved on the same object.

The two Stage 1 rules are:

  1. Remove name:<lang>N when its value exactly equals name:<lang> on the same object.
  2. Remove any numbered language-suffix key when its value is already present as an exact semicolon-separated value in the accepted target key on the same object.

Examples of the second rule:

name:en1=Example
alt_name:en=Example;Other name

or:

old_name:en1=Old example
old_name:en=Old example;Older example

In both cases the numbered value is already present, so Stage 1 only removes the duplicate numbered key.

Stage 1 will not:

  • change name, name:en, name:he, name:ar, or other unnumbered name keys;
  • add new alt_name:* or old_name:* values;
  • merge distinct alternate names;
  • remove any numbered value that is not already preserved on the same object.

Current Stage 1 counts

Metric Count
Objects checked in current bbox snapshot 48268
Objects changed by Stage 1 3552
Numbered tags removed by Stage 1 3684
Objects with one Stage 1 removal 3500
Objects with multiple Stage 1 removals 52

Removal categories

Category Numbered tags removed
Exact duplicate of existing unnumbered key 3674
Already present in accepted semicolon target key 10

Random sample of 10 planned removals

Object Removed key Removed value Reason Existing key Existing value
node/1803030864 name:en1 Ha’Atsma’ut/Ha’Aliya exact_duplicate_of_name:en name:en Ha’Atsma’ut/Ha’Aliya
node/1803044300 name:en1 Connecticut Blvd/Dukhifat exact_duplicate_of_name:en name:en Connecticut Blvd/Dukhifat
node/1803086508 name:en1 Ya’akov Boulevard/Ha’Eshel exact_duplicate_of_name:en name:en Ya’akov Boulevard/Ha’Eshel
node/5210722141 name:en1 Basel/HaNassi exact_duplicate_of_name:en name:en Basel/HaNassi
node/5487893086 name:en1 HaTsiyonut Blvd/Smadar exact_duplicate_of_name:en name:en HaTsiyonut Blvd/Smadar
way/36967378 name:en1 Zefanya exact_duplicate_of_name:en name:en Zefanya
way/69782189 name:en2 Eilon exact_duplicate_of_name:en name:en Eilon
way/225074854 name:en3 HaSachlav exact_duplicate_of_name:en name:en HaSachlav
way/708213435 name:he2 חורב exact_duplicate_of_name:he name:he חורב
way/1299438506 name:en4 Duchifat exact_duplicate_of_name:en name:en Duchifat

Upload and rollback preparation

I have generated:

  • a Stage 1 .osc upload file;
  • a CSV listing every planned removal;
  • an object-ID Overpass query for exactly the changed objects;
  • a rollback command that can recreate the original tags using freshly fetched post-upload object versions.

Rollback would restore the original full tag set on the objects changed by Stage 1. The revert file should be generated from fresh post-upload versions, not from stale pre-upload versions.

Proposed changeset comment:

Remove duplicate numbered language tags whose values are already preserved on the same objects

Please reply within 24 hours if you see a problem with the Stage 1 rules, the scope, or any of the sampled examples.

2 Likes
20

I’m beginning to upload the changesets, but ran into rate limiting and bbox sizing issues, so it’s going to take a while to complete the changes for stage 1.

You can see the progress here: Changesets by TaggingReviewer | OpenStreetMap

1 Like