Neu erstellte landuse-MP mit nur outer

Liebe Mitmapper,

auf Grund der kürzlichen Diskussion im Forum habe ich auch mal wieder daran gearbeitet, ein Acker-MP zurückzubauen. Hierbei bin ich bei einem angrenzenden landuse auf einen User gestoßen, welcher landuses “verbessert”, dabei aber MP-Relationen schafft, die unnötig sind, weil sie nur outer als Mitglieder haben, manchmal sogar nur einen einzigen outer. Dies ist bei meinen Stichproben in fast jedem Changeset der Fall. Meine Vermutung ist ja ein systematischer Mappingfehler mit dem iD-Editor. Aktuell mappt er oder sie gerade überwiegend in Brandenburg. Fakten und Links untenstehend.

Da auf einen Changeset-Kommentar bisher noch nicht geantwortet wurde, aber fleißig weitere landuses editiert und MPs produziert werden, habe ich soeben noch einmal eine persönliche Nachricht geschrieben:

Fakten und Links:
user: wermak https://www.openstreetmap.org/user/wermak
aktuelles Beispiel: https://www.openstreetmap.org/relation/12285067#map=14/53.0457/14.2393
kommentierte changeset: https://www.openstreetmap.org/changeset/98798959?xhr=1#map=13/53.0743/14.2608

Hei,

Nun ich beobachte es immerwieder, daß iD gelegentlich unnötigerweise von sich aus MP-Relationen produziert, ohne daß der User es will.

Ich habe einige wenige solcher Dinge in meiner Region als Beispiele gelassen: https://www.openstreetmap.org/relation/12165072 Hier bin ich mit zu 100% sicher, daß dieses MP auf iD und nicht dem User zurückzuführen ist. Ich kenne den User WegefanHB auch persönlich und weiß, daß er niemals freiwillig solche Konstrukte produzieren würde. In diese Richtung muß man auch mal im vorliegenden Fall prüfen.

Sven

Ich hatte hier auch letztens einige dieser nur-outer-MPs korrigiert (also wieder zurückgebaut auf normale Polygone), wo als Mitglieder auschlließlich einzelne Wegstücke enthalten waren (so wie bei https://www.openstreetmap.org/relation/12280915). Alle stammten vom selben User, der ebenfalls ID verwendet hat. Ich vermute, dass bei Aufspaltung von Linien diese MPs automatisch erzeugt werden. Ab und an erhalte ich auch Mitteilungen eines anderen Users, der auch solche MPs erstellt hat ohne es zu wollen und mich bittet das zu korrigieren.

Da ich selber iD Nutzer bin, weiß ich, dass das passiert und ich weiß auch einen Weg, wie an das vor dem Hochladen beheben kann. Ich würde gern auch helfen, dazu muss aber der User wermak mal reagieren.

Kann jemand eine overpass Abfrage basteln, die genau diese MP dieses User rausfischt, die allermeisten sind ja noch in Version 1?

https://overpass-turbo.eu/s/13jd liefert Relationen vom Benutzer mit 2 outer ways und sonst keine anderen Member. Genaue Bedingungen kannst du ja je nach Bedarf selbst noch anpassen.

Relationen ausschließlich mit outer member von diesem Benutzer (unabhängig von der Anzahl der Member) geht auch: https://overpass-turbo.eu/s/13jj

…und zwar wie?
Ich kämpfe nämlich selbst auch mit diesem Problem.

Gruß aus dem kalten Neuwied

Danke, wollte vorhin noch nachfragen, ob das auch geht.
Kann man boundary noch ausschließen?

ja, einfach [!boundary] mit reinpacken, also rel!boundary

Eine Fläche besteht ja im Grunde aus einem way, dessen Anfang und Ende genau auf einem Punkt liegen. Wenn man diesen an einer anderen Stelle aufteilt, hat man zwei ways, die - damit die Fläche als solche erhalten bleibt - logischerweise in einer Relation zusammengefasst werden. Man muss nur die beiden ways (oder mehrere wenn nötig) wieder vereinigen. Mittlerweile macht das iD sogar relativ einfach (da habe ich schon andere Zeiten erlebt, wo das nicht ging)

Danke, perfekt.
Sind aber weltweit immer noch 2 MB Daten, hauptsächlich natürlich in Deutschland.

Ist aber ein nettes Werkzeug, dass man dem user mitgeben kann, die eigenen (unabsichtlichen) Fehler zu bereinigen. Je nach Lust und Laufe könne ja andere dabei helfen.

Aufpassen muss man nur, weil einzelne MPs dabei sind, die wermak nicht zu verantworten hat, sondern die vorher schon MPs waren und eventuell aus anderen ways zusammengesetzt sind.

Also global gesehen gibt’s etwa 203’000 Relationen mit genau einem outer Member (keine boundary), und so um die 2,3 Mio. Relationen nur mit outer Member. Insofern fällt das, was der Mapper da macht, eher in den Bereich Grundrauschen.

Nicht immer muss das auch unpassend sein, z.B. https://www.openstreetmap.org/relation/3001702 benötigt die Relation, weil way und Relation unterschiedliche natural tags haben und man das ansonten nicht wirklich gut abbilden kann.

Und wieviele davon wurden durch iD verursacht? Oder vielmehr durch unwissende user (und da werden auch noch ein paar von mir dabei sein). Ist also eher ein grundsätzliches Problem. Vielleicht reicht es, in iD ne Warnung zu implementieren?

Man hätte KISS ein separates Polygon für den Felsen zeichnen können, so wie es vielerorts woanders auch gemacht wurde. Auch das MP in diesem Beispiel ist nicht erforderlich.

JOSM macht das nicht, sondern weist beim Upload auf eine nicht geschlossene Fläche hin (zumindest bei mir).

Die Frage ist, warum man den Way einer Fläche überhaupt auftrennen muss, außer man möchte die Fläche aufteilen. Und wenn das passiert, schließt man beide neuen Flächen wieder, indem man die Punkte, an denen aufgetrennt wurde, verbindet. Ich denke, die MP-Problematik resultiert aus einer Fehlinterpretation vor allem von wenig versierten Mappern: Sie möchten auf der Grenze einer Fläche z.B. eine Wand einzeichen, und meinen, sie müssten dafür den Way der Fläche in diesem Bereich auftrennen und entsprechend taggen. Besser wäre es aber, einfach einen neuen Way (ggf. auch deckungsgleich mit dem Way der Fläche) zu mappen.

Genau, darauf wollte ich eigentlich hinaus. Wenn es da ein prinzipielles Problem mit iD gibt, besser gleich an der Quelle beheben, statt jeden Mapper damit zu belämmern.

Ich benutze reltoolbox um unnötige Multipolygone aufzulösen. Ihr auch?

@Mammi71
Hat sich wermak inzwischen gemeldet?
Ich habe ihm einen Kommentar gesandt, weil er in einer Busrelation Fehler eingebaut hat. Siehe
https://www.openstreetmap.org/changeset/97365873#map=16/48.8244/9.0682
Die Relation habe ich nun repariert, nachdem er sich nicht gemeldet hat. Vielleicht hat er keine Lust, auf Kommentare zu antworten.

Und was würde passieren, wenn Du trotzdem hochlädst?

Ich hatte da beim Überarbeiten und Verfeinern der Flächen auch schon öfters diese Fälle, wo es sich mit Auftrenne und wieder Zusammenfügen am einfachsten arbeiten lässt. Ein konkretes Beispiel habe ich grad aber nicht im Kopf. Das Verbinden der End-Punkte ist ja klar, ist hier auch immer der Fall. Nur sind dann jeweils beide Endpunkte zweier ways verbunden. Da muss man dann schon noch explizit ausführen, dass beide ways zu einem Verbunden werden.

Das kann ich für mich ausschließen und auch bei den Bearbeitungen dieses Users habe ich da nicht den Eindruck. Genau weiß ich es allerdings nicht, dazu müsste sich wermak äußern.

Wer von Euch ist in der Lage, ein entsprechendes Ticket zu schreiben? Ich bin da raus.

Sorry, das ist schön für Dich. Hier geht es aber um user, die MPs mit iD bearbeiten. Ja, das geht mit iD, Ja, das ist aufwendiger. Ja, man muss wissen, was man da tut. Nein, mit JOSM möchte ich nicht arbeiten. Ja, ich habs schon probiert. Ja, man kann auch mit JOSM Fehler machen, wenn man nicht weiß, was man da tut!

Nein, bisher nicht.

Ich nehme an, es wird eine unvollständige Fläche hochgeladen. Aber: Ich halte es für besser, jemanden darauf aufmerksam zu machen und die Chance zu geben, das Problem sauber zu beheben, anstatt im Hintergrund automatisch ein unnötiges MP zu erstellen, das dann beim nächsten Mapper zu Verwirrung führt.

Groundhog day war ja gerade, also passt der Thread mindestens in der Hinsicht.

Mal abgesehen davon, das unklar ist was sooooo schlimm an der Verwendung eines (einfachen) MPs im vorliegenden Fall sein soll. Ja es ist unnötig, aber es ist genau so unnötig “aufzuräumen”. Das “Problem” ist, wie schon dutzende Male erklärt, dass iD ein abstraktes Flächenobjekt verwendet und intern dafür sorgt das die Flächeneigenschaft korrekt bestehen bleibt, essentiell egal was der Benutzer macht.

Wenn der User aber jetzt eine Operation durchgeführt hat, die dazu geführt hat, dass aus einem einfachen Polygon ein MP wurde, z.B. ein Gebäudeumriss aufgetrennt hat, dann gibt es keinen einfachen automatisierten Weg zurück, da ja das immer nur ein Zwischenschritt in der Bearbeitung sein könnte. Die MPs bleiben also bestehen, jetzt kann es natürlich sein, dass die Entwickler vor gut 10 Jahren einfach ein paar Leute trollen wollten, aber ich gehe eher davon aus, dass sie sich damals nicht vorstellen konnten, dass man sich nach einem Jahrzehnt immer noch periodisch beliebig heftig über völlig korrekte OSM Objekte aufregen kann, die überhaupt keinen Schaden anrichten.

Multipolygone, die nur “outer” member haben, erstelle ich auch in großer Menge.
Z.B. ein breiter Fluß führt durch Mangrovenwälder. Da gehört ne Linie sowohl zur Mangrove als auch zum Flußbett. Aber nicht alle Linien des Flußbettes zur Mangrove. Oder umgekehrt. Und oft wurde ein Tel der Mangrove zu Plantagen gemacht, und der Fluß zieht auch dort hindurch…
=> das sind Fälle, in denen solche Multipolygone angemessen sind.