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.
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.
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.
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.
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.
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.