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 osm.org/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. osm.org/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 osm.org/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 osm.org/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 osm.org/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?

Hello release_candidate, DWG has received a complaint from a resident saying that the path osm.org/way/330874722 does not exist and is on private property. I realize it's been a while, but do you remember anything about adding this path and is it possible that they are right?

I notice that this problem is much bigger than I first saw. You have added thousands of nodes wrongly tagged. I will revert your imports.

In this changeset you have added the tag "boundary=protected_area" to all *nodes* making up the boundary of a protected area. JOSM should actually show warnings for that, please double check! Also from the amount of data you added this looks like an import. As you know imports require prior discussion in the community. Please show me where your import has been discussed. Thanks!

Could you please specify your sources exactly, as in give an URL where we can look at the sources you are using. I am especially suspicious of the large amount of circular holes in the forest you added here osm.org/#map=17/57.07518/24.17087 as they appear on none of the available aerial imagery. Thank you!

The almost-square residential area in this changeset looks wrong. There are buildings all around it which it should encompass!