Multipolygonwahnsinn - oder: Durchblick war gestern!

Das ist halt Micromapping, und das MP hat den Vorteil, dass man das falsche natural=grassland mit einem Schlag auf landuse=grass oder meadow korrigieren kann. :slight_smile:

Aber meiner Meinung nach sollte es trotz allem (auch) Teil von landuse=farm(land) sein.

Es könnte auch eine Art digitale Versiegelung sein, die verhindern soll daß noch irgendjemand irgendwas in dem Gebiet editeren kann. :slight_smile:

bye, Nop

Und da behaupte noch mal jemand, dass unsere Multipolygone kompliziert seien:

https://www.openstreetmap.org/relation/812190

3527 Member, davon gefühlte 3400 als Mikroinseln von einigen Quadratmetern. Natürlich ein Import.

Gruss
walter

Die ist aber korrekt oder?

Glaube schon. Ist mir zwar in meinen “Missing Boundaries” als defekt aufgefallen, aber der JOSM-Validator hatte keine Einwände (nachdem er 15 Minuten genudelt hat). Und heute war noch einer dran am machen am tun :wink:

Morgen früh wissen wir mehr.

Gruss
walter

Ach Gott, …man kann es wirklich übertreiben.

Ich grabe mal den geliebten Beitragsbaum wieder aus… Schließlich hat er ja immer noch Aktualität… auch wenn hier lange nichts geschrieben wurde…

Manchmal stoße ich auf Dinge, wo ich mir dann sage: ‘…ach macht doch euern Scheiß alleene!’ und breche einen Reparaturversuch mit JOSM bewußt ab (wie hier getan).

Der MP-Fehler hier (http://tools.geofabrik.de/osmi/?view=areas&lon=12.08514&lat=51.11394&zoom=18&opacity=1.00&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways) hervorgerufen durch in meinen Augen unnötige MP-Relationen ist ein solcher… sicher hervorgerufen durch einen Neuling, er kann dafür aber nicht unbedingt was… Den Fehler sehe ich in der sklavischen Anwendung von MP-Relationen, wo simple geschlossene Linienzüge reichen würden. Die Folge ist nun, daß solche Ecken stärker als andere geometriefehleranfällig sind…

Die anderen Edits vermag ich nicht einzuschätzen.

Sven

Ein Reparaturversuch ist sowieso nicht die Lösung der Wahl. Besser schreibst du den Bearbeiter an und erklärst ihm, wo das Problem liegt und was er falsch gemacht hat. Wenn es ein Neuling ist, ist er auf solches Feedback angewiesen, damit er den Fehler nicht immer wieder macht. Wenn es aber ein erfahrener User ist, dann besteht die Möglichkeit, dass ihm ein Flüchtigkeitsfehler passiert ist (den er nach einem entsprechenden Hinweis leicht selber reparieren kann) oder dass er das Multipolygon aus gutem Grund so angelegt hat und der Fehler gar nicht am Multipolygon, sondern in der Prüfroutine des Validators liegt.

In allen 3 Fällen ist es also besser, den Bearbeiter zu kontaktieren, statt selbständig etwas am Multipolygon zu ändern.

Hallo,

Ja, aber an der genannten Stelle haben wir es mit Altlasten zu tun. Das südliche Sachsen-Anhalt, der Nordosten Thürigens (hallo Mirko) und der Nordwesten Sachens haben ein Multipolygonitis-Problem (mancherorts auch keins). Das waren aber mehrere Mapper, nicht einer allein. Neulich (und heute wieder) habe ich einen per Änderungssatzkommentar angeschrieben, der Multipolygone liebt und unnötig viele anlegt.

Ich bezweifle, dass das in dem konkreten Fall hier hilft. Der Benutzer ist nicht mehr aktiv. In der Gegend hilft nur saurer Reiniger in Form des Reltoolbox-Plugins für JOSM.

Viele Grüße

Michael

Naja… mein Problem bei solchen Dingen ist, erst mal selbst zu verstehen, was passiert ist und worin der Fehler liegt, um dann erst mal in der Lage sein zu können, dem User das Problem zu erläutern zu können… Alleine wenn auf ich Fehler in solchen MP-Konstrukten, gemischt mit einzelnen geschlossenen Linienzügen stoße, hab ich selbst darauf dann mittlerweile keine Lust mehr mit reinzudenken… Hinzukommt daß iD anders damit umgeht, als JOSM und ich iD nicht kenne…

Es ist leider eine Art Resignation… :frowning:

Sven

Der Benutzer (KEV92 alias Mordler) war vorgestern aktiv, siehe https://www.openstreetmap.org/way/196474628/history.
Ein Reltoolbox-Plugin hab ich in meinem Leben noch nie gebraucht.

Wenn du ein Problem nicht erklären kannst, dann kannst du es erst recht nicht selber beheben. Vielleicht schaffst du es, den Validator zufrieden zu stellen, aber das heißt nicht, dass es dann inhaltlich stimmt.

Als Resignation würde ich das nicht sehen, wenn man Arbeiten jenen überlässt, die sich damit auskennen. Ganz im Gegenteil, das fällt im weiteren Sinn unter Delegieren - eine der Fertigkeiten, die einen guten Manager ausmachen.

Jeder hat seine Stärken und Schwächen, und erfolgreich im Leben sind jene, die sich dort betätigen, wo ihre Stärken liegen.

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