Multipolygonwahnsinn - oder: Durchblick war gestern!

Ich weiß schon in etwa, was da passiert ist, er hat einfach ein simples Flächenrestidenal drübergebügelt ohne das Vorhandene, komplett mit unnötigen Relationen erfasste zu beachten und einen MP-Stütztpunkt mitgenutzt… oder weil er mit iD einfach nicht wusste, wie man mit diesem unnötigen Landuse-MP-Sch… umgeht…

Doch es ich hier schlicht Resignation Ich hab manchmal einfach keine Lust in solchen Regionen Fehler zu beseitigen (auch wenn ich recht gerne Fehler beseitige)…

Ich kenne mit mittlerweile recht auch mit den komliziertesten MP-Relationen aus, nicht zuletzt weil ich in den letzten Jahren eine ganze Menge repariert oder auch aufgelöst habe… und weiß in etwa, in welchen Regionen ich was erwarten kann… und kam im Zweifelsfall auch meine Overpass-Abfragen um MP’s mit >1 Outer-Rolle bzw. Landuse-MP’s mit Straßen als Outer zu identifizieren…

Sven

Riesige place=archipelago und place=island Multipolygone verbreiten sich wie ein Krebsgeschwür.

Hier das neueste: Japanische Inseln https://www.openstreetmap.org/relation/9427189
Nur gibts beim Abruf in Turbo und OSM ein timeout.
Rufe ich die Relation in JOSM auf (nur Historie) werde ich gesperrt (too much data downloaded)

Sämtliche Tools laufen ewig oder schmieren ab wenn solch eine Relation im Wege ist.
Kann man so etwas nicht schlicht und einfach löschen, bez wem kann man das melden?

Das sind doch keine Multipolygone sondern boundarys

Ach ja: place=sea ist die neueste Mode

nö, solch eine Boundary gibt es in Japan nicht.

Ist sich weg, da es sich um eine Sammelrelation handelt, die keinerlei Funktion besitzt. Ausserden war das Teil technisch defekt, da es Geometriefehler besaß und kein sauberes Polygon bildete.l

Mutige Grüße
Walter

Unser Held des Tages. Ich war gerade dabei, zu versuchen das Teil mit JOSM zu ziehen - mit der Planet geht das aber natürlich viel schneller.

Also mit etwas Geduld hat JOSM diesen Extremfall geladen, aber ich denke auch, dass es besser keine type=multipolygon Relation wäre.
Geometriefehler hat er nicht entdeckt (Stand etwa 07:14)
Ansonsten habe ich das Ding gerade verwendet, um ein paar Verbesserungen an der JOSM Performance zu machen, ich frage mich aber, ob damit nicht sogar das Problem eher größer wird.
Je leichter es ist, mit JOSM solche Monster zu editieren, desto mehr sinkt ja auch die Hemmschwelle noch mehr davon zu produzieren.
Ein Teufelskreis?

Ich hatte in https://github.com/zerebubuth/openstreetmap-cgimap/pull/174 vorgeschlagen, Relationen generell auf 32000 Members zu begrenzen. Wenn ihr denkt, dass das eine gute Idee ist, bitte kommentieren/voten. Diese Grenze wäre im vorliegenden Fall fast gerissen worden.

Ich fürchte nur, das Leute, die an dieses Limit stoßen, dann anfangen, Wege zu verknüpfen bzw. extra Wege anzulegen, um wieder unter das Limit zu kommen :frowning:

Klar, es wird immer Spezialisten geben, die versuchen, auch diese Grenze zu umgehen. Auf der anderen Seite, wenn ich mir so die Relation für Honshu oder den Lake Huron anschaue, so sind dort heute schon viele Ways vergleichsweise winzig. Ich sage nicht, dass jeder Way unbedingt 2000 Nodes haben muss, aber 95% aller Wege mit weniger als 100 Knoten ist vielleicht auch nicht ideal.

osm2pgsql wirft alle Relationen mit mehr als 32767 Member übrigens weg, so dass es eh wenig bringt, so große Relationen zu bauen.

Den Mutigen gehört die Welt - ich 'trau mir das nicht.
Danke

Ich bin mal meine Filterregeln für das Planet File durchgegangen und 'hab die ordentlich erweitert.
Die “Place” Labels die ich brauche filtere ich dann raus, mach all-to-nodes und werfe dann die Relationen weg.
Kostet alles eine Menge Zeit und Resourcen nur geht das anders nicht mehr.
5 tage für die Japan.map sind einfach untragbar.

Wobei ich überzeugt bin das irgendwelchen Leutchen schon bis zum nächsten Kartenupdate ein neuer destruktiver Trick einfällt :wink:

In den guidelines steht eindeutig das man diese grossen places als Nodes taggen soll, ist aber vielen einfach egal.

Moin