These are historical names and were already given more properly using old_name:de key.

See also previous comment here: changeset/175082756

I'll revert this change.

I've reverted this change and related recent changes in this area.

It is true that distinction can be made between German-language words and words that are mere transcriptions but name:<lang> keys are not explicitly meant for exonyms, exceptional names or names of certain language origin. These language tags are used to store names that are just commonly used in given language, and are expected to appear on (modern) maps in given language, which includes transcribed names.

A few users have expressed a view that transcriptions shouldn't be stored in OSM at all because in theory transcription can be automatic but in reality there likely isn't any data consumer that can transcribe names reliably, so that relevant transcription system for each language is selected in the first place and many possible exceptions are handled properly. So if transcriptions were just ditched from OSM it'd mean that language specific renderers would be pretty much stuck with name variants that are definitely inappropriate in given language.

The way you change names is in first place problematic because you present historical names as if they were current names, which is grossly misleading. As I already pointed out earlier (changeset/176862757) old_name:de key exist for names that not current and in most cases names that you add already were present using that key.

Note that this kind of edits have been reported to DWG in the past already have been reverted as inappropriate (see changeset/36561697).

Please not that German-language Wikipedia article that you refer above is titled "Kaliningrad" not "Königsberg". The latter is a historical name and was therefore already provided here more properly using old_name:de:1255-1946 key. Due to your edit this historical name is displayed on German-language maps that are otherwise up to date, which is misleading.

way/978580063 – this way is for protected area boundary[1], as indicated by tags for the parent relation, and protected area boundary is not coincident with landuse/park boundary. So I'll restore it.

User who originally added the protected area boundary made its some other segments coincident with landuse boundary as these are more close to one another around these other segments, but that's also inaccurate, and I believe it'd be better to map these separately as well.

[1] https://register.keskkonnaportaal.ee/register/protected-nature-object/1416

You added several reedbeed areas as islands (inner areas) in lake relation, e.g. way/290242536 and way/290240794.

On maps by the Land Board these are not mapped as islands. They draw the shoreline based on recent lidar data, and if certain shallow areas are not mapped as islands based on this data then this indicates that these areas are below the mean water level. This official eleveation data is generally followed around Estonian coastline and lakeshores.

Note that the latter one of these two examples is even named as a shallow ("madal"), i.e. an underwater relief.

To my understanding it is fine to map redbeed on both sides of the shoreline.

I now kept only the smaller one of two Kulje bays, in its verifiable extent between Kulje and Podmotsa: way/1379845935

Parandasid siin ära lühendi "pkr". Ma olen seda lühendit ja ka lühendit "kr" (kraav) kasutanud Maa-ameti kaartide eeskujul. Sarnaselt on OSM-is kasutatud vist enamvähem läbivalt ka teenimedes lühendeid "mnt" ja "pst". See tundub mõistlik, kuna pikalt välja kirjutatud sõnadega on kaart kirjum kui tarvitseks.

Siin on millegipärast tee (way/53502922) tükeldamisega kõrvalmaantee (relation/2892332) poolikuks jäänud.

Sama veel näiteks way/23636866 puhul.

Kas see on samuse osm-relatify viga?

Või eks või siis esialgu ka teisendada neis piirides rahvuspark Ramsari alaks (ramsar=yes + protect_class=98).

See viimane on Ramsari ala, mis laenab nime rahvuspargilt ja mis kattub rahvuspargiga selle varasemates piirides. Natura ala (linnuala) on veel kattuv. Need on n-ö rahvusvahelised alad, mis on euroliidu liikmesriikides kaitstavate alade seast teatud kriteeriumite järgi välja valitud.

Aga reaalne kaitseala, millel on kaitsekord ja mis on looduskaitseseaduse mõistes rahvuspark ja mis on looduses tähistatud, on ikka see, millele eespool viitasin.

Rahvuspargi kaitse-eeskirja muutmisest ja muu hulgas laienemist on juttu siin: https://keskkonnaamet.ee/vilsandi-rahvuspargi-kaitse-eeskirja-muutmine#tutvu-kaitse-eeskirj. Pindala suurenes üle kahe korra.

See protect_class tegelikult ei käi terve kaitseala kohta. Eestis on vastavad IUCN-i kategooriad määratud kaitsealade vöönditele. Siin nt: Rohusi skv – 1b, Rammu skv – 4, Koipsi skv – 5.

Arvatavasti on selgem neid IUCN-i kategooriaid ühegi kaitseala (RP, LKA, MKA) juurde mitte lisada. Mõnel juhul küll on kaitsealal üks vöönd (nt siin:
relation/18255934), aga IUCN-i kategooria käib ikkagi kokku vööndiga, millel on teine nimi ja ka teine KKR-kood.

Rahvuspark on nüüd oluliselt teistsuguse välispiiriga: https://register.keskkonnaportaal.ee/register/protected-nature-object/1021

Kuna litsentsiküsimus on ikka lahendamata, Keskkonnaagentuur teadaolevalt pole loobunud teatud õigustest (CC BY 4.0 waiver), siis vana piiri asendamine uuemaga oleks probleemne. Vist peaks siis vananenud andmed kustutama.

Siin on Lubja klindiastangu MKA-st välja jäänud väiksem lahustükk teisel pool Lubja teed.

way/886644549 – nature reserve "Haapse rannamännik" is added here.

There is no such nature reserve. I also can't find name "Haapse rannamännik" from elsewhere, and it is unclear why only this small section of coastal pine forest is described as coastal pine forest. This should probably be deleted as unverifiable.

This protected object (hoiuala) for the most part encompasses the sea are between Saaremaa and Muhu islands. So mapping it as an individual protected object at given location is quite misleading.

I think the sign should be mapped and tagged more clearly as a sign but I'm not sure what tag(s) would be appropriate. Maybe sign=yes + inscription=<text> is sufficent. Or maybe something like "sign=protected_limit" should be invented (cf. city_limit). That kind of signs are common and it'd be good to map these in some consistent way.

I think subareas shouldn't be added. In Estonia to my knowledge we haven't adopted any specific data schema that makes certain use of subarea roles in certain situations.

As per relation type documentation[1] subareas are generally not needed, and unnecessarily make future edits more difficult. Also relations are not supposed to be used as mere categories[2], they are supposed to represent an individual geographic object[3].

Also please note that these town neighbourhoods are not really administrative divisions, if that's what you meant to imply with this kind of use of subareas and your changeset comment.

[1] osm.wiki/Relation:boundary
[2] osm.wiki/Relations_are_not_categories
[3] osm.wiki/One_feature,_one_OSM_element

Is there a particular reason why you readded subareas to county relation?

As per relation type documentation[1] these are not really needed, and also, if subcategories are collected then it seems to be forgotten that relations are not categories[2].

I considered updating the list of subareas here along with updating particular subarea relations, but due to aforesaid reasons, and also to make future updates easier I ended up removing subareas instead.

I see some other counties in Estonia (not all) also have subareas set, and so maybe you wanted to make things more consistent. I suggest that we should rather drop subareas for other counties that currently have these, the way it is done for some for admin entities in some other countries.

[1] osm.wiki/Relation:boundary
[2] osm.wiki/Relations_are_not_categories

Based on which source name "Кулейский залив / Kulje laht" is added to way/1379845935 here?

In Estonian-language sources that I find "Kulje laht" is used for smaller water area between Kulje and Podmotsa, i.e. way/1379845934. E.g. see this map: https://xgis.maaamet.ee/xgis2/page/link/VBgrJJ-z

In any case, as per "one feature, one OSM element" there probably shouldn't be two OSM objects with the same next to eachother, and rather it needs to be figured out what is the correct extent of this bay.

Names like "Gussew" are actually regular and common transcriptions of current place names, not wrong names, and are also used as German Wikipedia article titles[1]. For old German-language names "old_name:de" tag was already used.

You might want to check Wikipedia guidelines[2] that are probably helpful here as well. OSM generally stores up-to-date data, and so there probably isn't any more reason here to prefer old name variants over ones that are actually used in modern German.

[1] https://de.wikipedia.org/wiki/Gussew
[2] https://de.wikipedia.org/wiki/Wikipedia:Namenskonventionen#Geographische_Namen