Doppelte Member in Riesen-MP-Relation entfernen

Moin,

mir ist gerade vorhin die Relation 6040654 aufgefallen, +12000 Member, fast alle doppelt (mit gleicher role).
Die Relation soll wohl die Insel Irland beschreiben (place=island). Ich lasse mal beiseite, ob das sinnvoll ist.

Mit JOSM (10526) kann man diese Relation nicht wirklich sinnvoll bearbeiten, daher habe ich die Daten als *.osm
gespeichter, im Text-Editior die doppelten Zeilen entfernt und ein action=modify hinzugefügt.
Leider kann JOSM auch mit der vereinfachten Version nicht umgehen, ich kann also nicht prüfen,
ob die geänderte Rel okay ist. Das Programm mkgmap meldet jedenfalls Fehler, dass das multipolygon nicht geschlossen ist.

Ich frage mich jetzt,
a) Gibt es einen geschickteren Weg, doppelte Member zu finden und zu entfernen?
b) Gibt es vielleicht einen Trick, um JOSM so zu beschleunigen, dass es mit solchen Monstern umgehen kann? Irgendeinen Option?
c) Gibt es irgendeinen Fall, in dem ein doppeltes Member in einer MP-Relation sinnvoll ist?
Wenn nein, könnte man wahrscheinlich einen BOT dafür bauen?

Gerd
P.S. Habe zunächst bei den Iren geposted, aber da scheint kaum jemand aktiv zu sein.

Ich bin dran. nachher erklär ich dir ob und wie es geklappt hat.

gruss
walter

ps:Nimm das United Kingdom Forum. Die kümmern sich oft auch um Irland.
oder noch besser talk-ir

Muss kapitulieren :frowning:

ich bekomme zwar alle Doubletten raus, möchte danach aber die Rel sortieren und das dauert.

Mein Weg:

  • leere Ebene
  • mit “Daten herunterladen” nur die Relation laden
  • im Rel-Editor alle member löschen
  • Suche auf “type=way”
  • diese wieder einfügen
  • Rolle auf “outer” setzen
    . Sortieren — und da klemmt es fürchterlich.

Sollen sich die Iren drum kümmern.

Gruss
walter

Ja, genau da klemmt es auch bei mir.
Der JOSM code zum Handling von MP-Rels ist im Vergleich zu dem von
mkgmap relativ einfach gestrickt. Ich werde vielleicht mal versuchen,
die mkgmap Optimierungen in JOSM einzubauen.
Ein generelles Problem in JOSM ist, das die darzustellenden Flächen
bei diversen Aktionen neu berechnet werden, auch wenn
sich an den Daten nichts geändert hat. Da ist sicher viel Raum
für Verbesserungen.

Gerd

Löschen und einen place-Node in die Mitte setzen. :wink:
SCNR

Chris, das empfinde ich als die einzig sinnvolle Lösung.

Allgemein zeigt das Beispiel sehr gut, dass OSM für solche Objekte einen anderen Definitionsansatz braucht. Wenn man die Mega-Flächen als ganzes nicht merh warten kann, dann muss man die Mega-Flächen aus kleineren Flächen zusammensetzen.

Das Problem ist nur, wie bekommt man die Mapper dazu: Meiner Meinung nach durch konsequente Weigerung der Auswertung ab X Mitgliedern einer Relation. Bspw. mkgmap (oder anderes Tool) liest Relationen ein, wenn Mitglieder größer 5000, dann Relation verwerfen.

Reicht es nicht, erst mal nur die doppelten zu löschen? Sortiert ist ja schon recht gut.

Nachtrag, ich bin da dran, also falls sich noch wer die Mühe macht, rechtzeitig stop sagen …

Sortieren reicht nicht, weil die Relation auch dann noch fehlerhaft, sprich, nicht geschlossen ist.

Ja, das ist mir klar, das gehört für mich egtl. zusammen :wink:

Edit: ma schauen, in wieviele Konflikte ich reinlaufe…

Bäm: https://www.openstreetmap.org/changeset/41110934

tnx

Das Gleiche dürfte auch für Großbritannen gelten https://www.openstreetmap.org/relation/6038068
place=island ist dort, IMHO unnötiger Weise, gesetzt.

Lässt sich weder in JOSM - reichlich zugeordneter RAM - oder auf der Webseite öffnen oder bearbeiten

Bernd

Wenn ich den Kommentar zum ersten CS richtig verstanden habe, gibt es die Relation nur, um
den Umriss der Insel zu markieren.
Ist aus meiner Sicht nicht falsch, nur ist es halt eine ziemlich komplexe Relation.

Danke, hattest Du einfach nur mehr Geduld oder eine bessere Methode als die bisher genannten?

wie ich oben anschnitt; ich hab aus der Relation nach und nach die doppelten member rausgelöscht (die sind zum Glück andersfarbig im Editor). Dabei drauf geachtet, viele zusammenhängende (sortierte) für den Schluss aufzuheben. Zwischenzeitlich aus Versehen auf Sortieren geklickt … und wg Crash von vorn angefangen.
Und dann mit viel Geduld, Fluchen und 1,5GB Ram die Relation (“Kreis”) geschlossen.

Ich habe ein Stück Grenze geladen und dann via “unvollständige Elemente herunterladen” den Rest geholt. Ladezeit etwa 2 Minuten. Korrekturzeit nochmal 2 Minuten.
Edit hups, falsche Relation, ma schauen.

Dort war eine Lücke im Polygon.

Ich hab die Relation aus Overpass nach JOSM exportiert, allerdings ohne nodes. Das spart eine Menge an Speicherbedarf und reicht fürs Sortieren aus. Nach dem Sortieren die Ways an den offenen Rändern dazugeladen. Die fehlenden Ways durch laden der Elternlinien der Endnodes geholt und zur Relation hinzugefügt, bis der Ring geschlossen werden konnte.

Ich habe mir mal angeschaut, was da klemmt. Nach dem Sortieren wird ermittelt, welche Member betroffen waren,
um diese zu “highlighten”.
Es gibt da eine Schleife, die dann sequentiell für alle Member aufgerufen wird und wiederum seq. alle
bis dahin verarbeiteten Member durchsucht. Bei > 6000 Membern kommen
da 'ne Menge Durchläufe zusammen, etwa sowas wie 21 + 32 + 43 + … 60005999 …

Ich habe nicht verstanden, was da genau passiert, aber man kann das deutlich beschleunigen,
indem man ein HashSet anstelle einer ArrayList verwendet. Damit reargiert JOSM nach dem Sortieren auf meinem
Rechner wieder innerhalb von Sekunden.

Ich muss jetzt mal schauen, wie ich diese Info an die Entwickler weiterleiten kann.

Gerd

https://josm.openstreetmap.de/newticket

Da ein neues Ticket aufmachen und dann Problem beschreiben und wenn du hast ein diff anfügen.