Thank you for the information. But this alone is not a reason for a non-closed admin relation.

The normal way to do this would be to have a new relation with admin_level=8 for the new, merged community and to put the old relations down to a nother admin_level (9 or 10).

As far as I can tell, this was exactly what was done in changeset changeset/36303028.

So I don't think the "old" boundary between the villages should be removed, just "degraded" to not being a boundary between communities, but to community districts, see also boundary=administrative.

This change made relation/154495 be not closed any longer. Was this intended?

Che change a changé relation/154495 alors elle n'est fermée. C'était volontaire?

We are not a playground here for some unknown, dubious test projects.

Bicyclist,

gehst du im "echten" Leben auch so mit deinen Mitmenschen um?

"Dein Rumgeheule"? Echt jetzt? Das empfindest du als angemessenen Umgangston?

Na dann viel Spaß weiterhin.

But why were the old ones not deleted (or maybe just kept)? This (kind of) destroys the change history (resp. makes it harder to follow).

Then shop=electronics ist just plainly wrong.
It should probably be something like power=pole and transformer=distribution.

Way are there so many electronics shops in the middle of a street?

Really? A shop in the middle of a street?

It's like "I know I am disturbing, but I don't care".

If it is fake, and you only added it for personal benefits, it doesn't belong here.

It would be useful to split these works by region in order not to create such (spatially) large changesets.

This changeset destroys some administrative boundaries. I just reverted the deletion in changeset/54760278.

I suppose that it was an error to delete these parts.

I wouldn't have, too. But there is a great tool which automatically collects the boundary errors from yesterday :-)

https://wambachers-osm.website/index.php/10-osm-reports/1109-countries-compare-2017-12-15

Hi! Alas, this destroyed some boundaries. I fxed them by partially reverting this changeset.

Hi! Could you please have a look at relation/2788560? It is broken since then.

Beim Brucherbach liegt mir eine (leider nicht OSM-fähige) Quelle vor, bei der der Gemarkungsgrenzenbverlauf signifikant vom Lauf des Brucherbachs abweicht.

Bei der Blies ist es, wie du sagst: da läuft die Grenze teilweise auf deutscher Seite.

ah, danke für die Info, war mir neu.
Meine letzte Info war, dass nach dem Tod des früheren Bewohners das Anwesen von Leuten aus der Nachbarschaft aufgekauft wurde…

Da die Postbezeichnung ja wohl immer noch so lautet: sollte der Restbestand nicht dennoch weiterhin so heißen?

I am sure Louisville is still an administrative entity, so I restored it as it was.

Ich glaube nicht, dass das Zusammenlegen von Grenzlinien und Bächen so eine gute Idee ist. Auch wenn die Grenze ursprünglich einem Bach- oder Flusslauf folgte, und der Lauf sich ändert, bleibt die Gemarkungs- oder gar Landes- oder Bundesgrenze, wie sie war. Von daher finde ich das keine so gute Idee.

Hallo und willkommen bei OSM!

Konsens im Forum ist, Multipolygone nur dort zu verwenden, wo sie erforderlich sind, d. h., wo es beispielsweise innere Flächen gibt, die "ausgestanzt" werden müssen.

Das ist im hier vorliegenden Fall nicht gegeben.
Die Fusionierung dieser Flächen war jedoch eine gute Idee, ich habe mir daher die Freiheit genommen, die Flächen (unter Zuhilfenahme der alten Flächenobjekte, aber ohne Multipolygone) zu vereinen.