Aber wir mappen doch "on the ground". Solange noch Fragmente irgendwo zu sehen sein, ist es m. E. nicht falsch, die Relation zu behalten.
Zumal so nun die Gefahr besteht, dass jemand wieder eine neue Relation anlegt.
Was hieltest du davon, die Relation wiederherzustellen und sie als "discontinued" oder so zu markieren?

Darf ich fragen, was dir an "type=boundary" / "boundary=administrative" falsch erschien?

Hi, it's me again. Could you have a look at relation/128381 again? There seems to be another overlap, created by changing way/34121641. Note that the relation already contains an inner way which cuts out a part of the town.

Now that was unplanned, sorry. I supposed to do several changesets instead of one big one.

Could you please have a look at relation/3445109? It is now broken after your change.

Could you please have a look? This changeset left relation/2586184 (La Paz) open and thus broken. Could you please fix it?

About the data sources, the PDF I found was just a first short search, just to have a look about what is now the real thing and what not.

But now, that we talking about that, thanks for your JPG. Having a look at it, I now think hat we have different scope:

way/439488910 is the very southmost border of the KW&W National Monument, i. e. the line between T2 R8 WELS (see the PDF) and the National Monument (whose borders are green on that JPG). It doesn't even appear at the JPG as it is cropped a little bit at the bottom.
OTOH, the dotted line you talk about is not present on OSM yet.
Maybe that already cleans up all confusion, and you should consider this on your further edits.

Have a nice day!

Now, maybe I was a little bit harsh. Sorry for that, I think it is better to get it along like civilized people. :-)

> Hey! I'm not just "destroying multipolygons at…will."

I am sure you do not intend do. But, in fact, your action removed a common part of two existing multipolygons. That is a thing that can happen by accident, in Germany we say "it's not a broken leg". But I think it is legitimate to fix it when one is pointed to that. And the most simple thing in this case is (for me) to just restore the line which was removed (apparently accidental). That's why I stepped in at the first place.

> I simply wish that when someone steps into an area, that more coordination happened between editors towards the same end rather than towards cross purposes.

This is normally what I as well think about the correct behaviour, and that's why I let local people normally do all changes. But in my opinion, structural changes (where the integrity of borders and other multipolygons is vilated) are excluded from this. Besides that, I think if someone finds an edge of an area to be erroneus, it is better to fix it (after having gotten the necessary data needed for that) than to remove it altogether. But I realize that other people might think different about that.

Having read about your experience with that other guy, I can understand your harsh reply, Although it is a small difference between a restored line and a bunch of streets, I absolutely can understand that you were upset.

If, however, you feel the need to remove it again, I won't be able to prevent you from doing that. I am going to retract myself from your region and let you destroy multipolygons at your will, but don't be surprised if that reduces OSM's overall usability.

Sorry, I saw your second change right now.

I am sorry to meddle with you work, but OpenStreetMap is a community project where everybody is welcome to contribute.

You have told me what you don't like, I, on the other side, don't like it when people randomly remove boundary parts and leave admin relations open and incomplete. Even if this boundary part is slightly misplaced, removing altogether is not good.

I am not watching over your shoulder concretely, I am just looking at the admin relations found to turned defective by (as in this example) https://wambachers-osm.website/index.php/10-osm-reports/1316-countries-compare-2018-08-09.

I am definitely not going to remove this part again, as I am sure "Katahdin Woods and Waters National Monument" has a south boundary and "T2 R8 WELS Township" has a north boundary. Removing them would harm the integrity of said boundaries/multipolygon, and repairing things is not "over zalous", as you call it.

Mmmm… according to https://www.nps.gov/kaww/planyourvisit/upload/Katahdin-Woods-and-Waters-Recreation-Map.pdf, the boundaries seem correct. (While this may not be a legal data source for changes, I think it can happily be used for arguing a "non-change"…)

If you know the correct location, may I ask you to just correct it? I am not from there and only help (among others) to fix boundaries which are structurally broken (such as missing lines which result in incompete relations).
The correct way to fix that is to move the points or to have the lines (ways) touch each other as they do now. If you need help doing that, feel free to ask again.
I try to move the line further to the North in the meanwhile.

The other one was incomplete as well, so I reverted this changeset. I hope you are ok with that.

May I know what was wrong with the deleted line here? Its deletion left the respective relation (T2 R8 WELS Township, 8439730) broken.

I don't know what was wrong with Gadingharjo (5615676) and Srigading (5615521), but this changeset leaves them broken. I fixed them in changeset/61490921.

Could you please verify these changes? By moving some of these points, you made relation/114487 overlap itself. See relation/114487 for details: in the south east, around "Brian Place", the two parts of the multipolygon overlap each other now.

An admin_centre must be a node, not a way. I hope you don't mind that I will revert this changeset in order to correct the issue.

You accidentally removed one line of the boundary relations. I restored them in the meanwhile.

I suppose it was a mishappening to change the whole area of Nikosia to a "site" and reverted this change.

Why? And why in this form?
If you have a look at power=sub_station, you can see
"Do not, however, attempt to automatically change occurrences of power=sub_station."