(That was the incorrect continent node, the correct one is openstreetmap.org/node/12098430255)

Place=continent is only used 9 times, and only as node. Plus there already exists a (somewhat questionable) Australia continent node node/1209843025

But how did you think that an area that only consists of mainland Australia could represent a continent? Is Tasmania not part of the Australian Continent? What happened to Papua New Guinea (and should it be the entire island, or just half of it)?

The only reason this is tagged like this is because people disagree with calling it a place=island. Not so that someone who has already thoroughly been told why attempting to clearly define the geographical shapes of continents is a bad idea (https://community.openstreetmap.org/t/america-relation/136587) can just go around and retag it without doing even an ounce of research into what people even consider 'the continent of Australia' to be.

If you want to go and clearly figure out and describe what a boundary=land_area is, go ahead, good idea. But don't just change tags that you don't understand.

Why do you keep constantly making these big undiscussed and badly thought out changes to places on the other side of the world from you? I have reverted this changeset.

changeset/178394794

*node, not a way

Hi, please fix your editor. You are mixing up ways and nodes. This is the object you intended to fix: way/83992026

Reverted changeset that dragged a way halfway across the globe

changeset/178369402

Hi, I see that you deleted a lot of `
construction:railway:etcs=2` tags here. Does this mean that this railway no longer has any etcs signalling?

Thanks for pointing that out. I did not notice that the member relations were also modified. I've restored the original situation in: changeset/178039405

Reverted pokemon-go edits

changeset/178015318

Reverted pokemon-go edits

changeset/178015318

Reverted pokemon-go edits

changeset/178015318

Reverted pokemon-go edits

changeset/178015318

Reverted pokemon-go edits

changeset/178015318

Reverted pokemon-go edits

changeset/178015318

I appreciate what you were trying to do here, but you simply have to first make sure you are following the import guidelines. This is not optional.
osm.wiki/Import/Guidelines

A screenshot of the written permission can be linked on this page: osm.wiki/Contributors

Hello Aleksandar (and the others on your team no doubt),
Thanks for getting back to me so quickly.

I'll address that last point first. Woodpeck states that it "can be useful", I find it hard to interpret that as him stating that this import can go ahead.
The diary post itself is from almost 7 years ago, it talks about 4500 datapoints and one from a different source. The post itself talks about written permission, but I was unable to find this written permission myself.

The data that has been imported over the last 4 months itself amounts to over 28k datapoints and was imported with the knowledge that there were many glaring issues going on that would need to be fixed *after* the fact.

Most of these datapoints included incorrect tag usages and other data issues such as:
* mapping natural=coastline or natural=water as a point.
* Included the undocumented source:type or misused the source:name tag.
* The description and source:type tag seem to duplicate eachother a lot of the time, or simply state "Ø", which I interpret as empty or null.
* fixme tags stating that the exact location still needs to be determined.
* A lot of these objects were already on the map, leading to duplicate objects.
* Another undiscussed import by them 4 years ago left behind a number of `OFFICIAl=*` tags which are still there to this day. Meaning there is no guarantee all this data will eventually end up getting fixed. changeset/109415380
The import guidelines exist exactly to prevent thes sorts of things from happening. osm.wiki/Import/Guidelines

The issue with your team here is the copying of data from nodes to new or existing objects. You've essentially made it imposible to easily revert all this data due to the hundreds of changesets that moved the imported data onto existing or new objects.

I was not made aware of the fact that these names could be plainly found in available/usable topographic maps of Greenland. If this holds true, then I think it might be ok to just remove the source:type and description tags you and your team have copied over, but I will first need to have a closer look later when I have time available. I will get back to you with that.

In the meantime, please keep your efforts at fixing this import in Greenland paused.

See also my discussion with andershl here: changeset/176706570

Best regards,
Taya Snijder,
On behalf of the OSMF Data Working Group

Hello,

Please cease attempting to fix this import in Greenland. It was undiscussed and will be reverted.

Also, in the future, please make sure the import you are attempting to fix was actually discussed by the community. Your involvement has made reverting everything significantly more complex.

Best regards,
Taya Snijder,
On behalf of the OSMF Data Working Group

Hello,

Please cease attempting to fix this import in Greenland. It was undiscussed and will be reverted.

Also, in the future, please make sure the import you are attempting to fix was actually discussed by the community. Your involvement has made reverting everything significantly more complex.

Best regards,
Taya Snijder,
On behalf of the OSMF Data Working Group

Hello,

Please cease attempting to fix this import in Greenland. It was undiscussed and will be reverted.

Also, in the future, please make sure the import you are attempting to fix was actually discussed by the community. Your involvement has made reverting everything significantly more complex.

Best regards,
Taya Snijder,
On behalf of the OSMF Data Working Group

Hello,

Please cease attempting to fix this import in Greenland. It was undiscussed and will be reverted.

Also, in the future, please make sure the import you are attempting to fix was actually discussed by the community. Your involvement has made reverting everything significantly more complex.

Best regards,
Taya Snijder,
On behalf of the OSMF Data Working Group