Dear Lex Legis, please try to use good changeset comments instead of just "." - you are an experienced mapper and you should be setting a good example for others. osm.wiki/Good_changeset_comments has an explanation of why this makes sense.

If possible, please try to keep your changesets to one continent, and open a new changeset for edits in a different continent, just so that the bounding box doesn't span half the planet. Thanks!

In case this is still an issue for anyone, here's a DWG statement on it: names in foreign languages are a rare exception to the "on the ground" rule. The group of people who have the best knowledge about the Thai name of a river in Finland are most like Thai mappers, not Finnish mappers. If the Finnish mappers then revert the Thai name because "this river is on Finnish terrain" then that is silly. HOWEVER, there may be situations where political sensitivities dictate a cautious approach; for example, when a German mapper happily adds German names to formerly occupied places in, say, Poland, that will have a sour taste for the Polish mappers and it *could* happen that the DWG would ask these mappers to tread carefully. So: in general, you cannot say that just because this is Ukraine the Ukrainain mappers get to define every name in every language for an object. But at the same time, Russian mappers should act with some caution. And a side note: We generally don't map pure transliterations.

In this changeset you "converted" a mosque in Mosul into a synagogue without giving any sources or reasons. Could you explain what information led you to make this edit?

KKS, it was not necessary to delete the "tourism=artwork" here. Yes I am sure opinions can be divided about what is art but try to err on the side of being friendly towards other mappers.

Dear Jon, using the Bing "bird's eye" images is not permitted on OSM (Bing have only granted permission for the standard aerial imagery). Please don't use it.

Organised editing teams (like yours) are expected to have documentation on the Wiki that outlines what their targets are and what sources they use in their work (see https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines). We'd expect Kaart to have (at least) one entry in osm.wiki/Organised_Editing/Activities. Among other things, this enables other mappers to give you a heads-up if they notice you're using inadmissible sources, and situations like this here can be avoided in the future.

Also, I disagree with creating groups of islands like the nNicobar Islands here relation/9493294 by taking all the individual coastline bits and putting them into one big relation in addition to the individual island relations they are already in. I also think that *if* such mapping made sense, using a type=multipolygon is the wrong relation type to use. If you feel a need to combine these individual islands into one group, I would make the individual island relations a member of a super relation, instead of duplicating information. Someone wanting to edit, say. the coast of Camorta Island will now not only edit a coastline way, but three relations. This is confusing to mappers.

Hello Olyon, I disagree with mapping bays, straits, channels, and various other named water areas as precise, hundreds-of-members polygons in OSM. I think a named node is sufficient. Using polygons means you are creating arbitrary cut lines between various bodies of water, like e.g. way/684290011. This kind of mapping is very difficult to maintain, prone to breakage, a burden on other mappers working in the area, and adds very little information. I would prefer it if you could stop copying this data into OSM from external sources, or else, have a proper discussion about it on one of the suitable international mailing lists before you embark on global mapping projects like this.

Alles vor Ort überprüft. In changeset/69761980 habe ich ein paar Geometrien etwas korrigiert, aber die Nummern stehen vor Ort definitiv genau so wie gemappt!

Ich hatte vor einigen Monaten schonmal auf die Problematik hingewiesen (osm.org/user_blocks/2517) und im Anschluss einige Änderungen von ulamm revertiert. Ich hatte gehofft, dass das "was ich irgendwo nachgucken kann ist öffentlich"-Missverständnis dadurch aufgeklärt wäre. In Deutschland gilt keinesfalls, dass Fakten automatisch ohne Urheberrecht sind, und es gibt sogar Gerichtsurteile, in denen gedruckte Topo-Karten eine Datenbank genannt werden. Also, bevor man aus der DTK was abschreibt, einfach nachfragen ob es ok ist. Nur: was machen wir jetzt mit all den ulamm-Edits der letzten Monate (oder Jahre), denen offenbar eine sehr liberale "jeder darf in die DTK schauen"-Auffassung zugrunde liegt? Offenbar sind ja nciht nur Namen aus Fremdquellen übernommen, z.B. ist für diesen Graben way/684354475, der in diesem Changeset hier erfasst wurde, die Quelle "bing imagery" sicherlich falsch (der Graben ist im Luftbild nicht sichtbar).

Dear Perrine L, thank you for your contribution to OpenStreetMap. In this changeset you have added more than 50 roads and marked them to be "secondary" roads, which is a relatively big type of road. On the available aerial imagery, these roads look more like agricultural tracks and hence could have been marked "track" instead of "secondary". Has anyone already contacted you about the issue?

(automatic translation)
Chère Perrine L, merci de votre contribution à OpenStreetMap. Dans cet ensemble de modifications, vous avez ajouté plus de 50 routes et les avez désignées comme routes "secondaires", ce qui représente un type de route relativement important. Sur les images aériennes disponibles, ces routes ressemblent davantage à des pistes agricoles et auraient donc pu être marquées "piste" au lieu de "secondaires". Quelqu'un vous a-t-il déjà contacté à ce sujet?

The areas you have highlighted are clearly low-quality mapping, and it is certainly worth analyzing and discussing whether the processes and funding model of HOT are currently adequate to create mapping with any long-term benefit. However, this was not what I was asking. My main point is that I would like you to write more accurate changeset comments. "Re-work 1234" doesn't really help a lot, because nobody knows what 1234 is, and nobody knows what you mean by "re-work". You could write "improve road classification" or "correct building geometries" or "remove invalid landuses". Or, if you desperately want to express your opinion on HOT's mapping quality, you can also write "Making sure this tile actually conforms to the instructions given in [URL] - it should never have been validated like that" or so. But a factual statement on what you're doing would be best, and if done well could also be helpful for the mappers whose mi stakes you are fixing. See also osm.wiki/Good_changeset_comments

So you are saying that when you "re-work" something you are ensuring that the data conforms to the instructions you quoted, and that the mappers using the tasking manager disregard these instructions?

Hallo rab, I assume that your "5833" is a reference to a HOT project but it is not obvious; can you make this clearer in your changeset comments? Also, can you explain why you are "reworking" something here - what are the issues you are fixing? If these are systematic problems, where the same mistake is made regularly, have you made an attempt to reach out to the mapper(s) responsible?

The changeset has been completely reverted becuause it looked like vandalism.

Why delete way/681639717/history ?

In this changeset described as "Atualizar escola e hotel" you have deleted many buildings, shops, and a residential area. Was the deletion a mistake, or is the changeset comment wrong? If the latter, what is the reason for the deletion?

Dieses Changeset hat eine Reihe von Häusern in der Straße "In der Treff" gelöscht, aber (entgegen dem Changeset-Kommentar) nicht neu gezeichnet: https://overpass-api.de/achavi/?changeset=67930452 - bitte erstelle die fehlenden Häuser oder nimm die Löschung zurück.

Is it intentional that the southern border of Taos Pueblo loosely follows the Carson National Forest border, sometimes leaving a little no-man's-land between the forest and the reservation, sometimes having both overlap a little?

This looks awfully wrong. Are you aware of existing rules about data imports in OpenStreetMap - that imports need to be discussed before they can be executed?