Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Zu den Zäunen und Mauern: Ich glaube, ihr wählt in der Debatte unglückliche Beispiele.

a) Wenn ein mit Zaun eingefriedetes Umspannwerk auf einem “Feld” steht, hat sicherlich niemand etwas dagegen, wenn der Zaun auf den Ring des Landuses “Umspannwerk” gelegt wird. Umspannwerk ohne Zaun geht nicht, Zaun ohne Umspannwerk wird es auch nicht geben, “reifliche Überlegung” sagt also: Ja, hier ist es vertretbar, Landuse und Zaun zu koppeln.
b) Meine Beobachtung in der Praxis ist, dass der Zaun gerne aus Bequemlichkeitsgründen auf die Flächengrenze gelegt wird (zB in P2 mit Shortcut “F” supereinfach), obwohl sich bei genauerer Betrachtung “on the ground” auch eine getrennte Führung beider Linien rechtfertigen ließe. Wenn eine nach heutigem Stand dauerhaft eingezäunte Kuhweide (Farmland) längs einer Straße liegt, und der Zaun erst einen Meter landeinwärts liegt, sollte “reifliche Überlegung” sagen: Späteren Mappergenerationen ist es sicherlich willkommen, wenn das Farmland etwas näher an die Straße herangezogen wird und der Zaun minimal landeinwärts gelegt wird, denn in fünf Jahren könnte der Zaun “on the ground” verschwunden sein. Ihn dann aus dem Landuse-Ring herauszufuddeln ist unnötig mühsam. (Microtagging-Überlegungen und landuse=road lasse ich jetzt mal außen vor).

@Nakaner:
a) In den bekannten Problemregionen gehen Multipolygonitis und Verkleberei Hand in Hand. Deswegen würde ich das nicht trennen.
b) “dürfen” ist weicher als “sollten”, nur “dürfen nicht” ist härter als “sollten nicht”. Hier ist positiv formuliert, also “dürfen” (weich).

@AB-inf-x-chg-AB: Warum keine Hilferufe an die MP-Ersteller? Die großen Multipolygonkünstler sind zum Teil nicht mehr aktiv, zum Teil sehr - sagen wir es mal vorsichtig - “individualistisch” unterwegs und allergisch gegen Eingriffe in ihre Kunstwerke. Deswegen ist ein Hilferuf dort nicht erfolgversprechend.

**@Mammi71 **Da hast Du mich erwischt. Landwirtschaftliche Nutzflächen sind aber auch das Einzige wo das lt. ThürNachbG gilt.

Auch wenn ich mich jetzt wiederhole: Ich mappe eine Einfriedung an der Stelle, wo sie ist (Luftbild bzw. Vor Ort Besichtigung); nicht an der evtl. abweichenden Grundstücksgrenze und auch nicht wo sie evtl. sein sollte, um Vereinfachungen zu erreichen. Und wen eine Deckungsgleichheit mit Flächenrändern vorliegt, dann ist es halt so.

Vielleicht sollte man den von mir kritisierten Satz auch so schreiben:
*
Einfriedungen, wie Mauern, Zäune o.ä. sind grundsätzlich an Ihrem tatsächlichen Standort, entsprechend Luftbild oder Vor-Ort-Besichtigung, zu mappen. Deckungsgleichheiten mit Flächen sind gründlich zu prüfen, ob Deckungsgleichheit vorliegt.
*
@Pfadfinder Bei Landuses bin ich mit Dir einer Meinung. Dann sollte aber der Landuse dem Zaun angepasst werden. Der Landuse ist virtuell der Zaun ist wirklich da.

Zum Thema Weide: Wenn die Grasfläche über den Zaun hinausgeht, ist das auch so zu zeichnen. Wenn es deckungsgleich ist, dann eben auch so.

Was mich an dem Teilsatz aus Punkt 4. eigentlich stört, ist, das damit unterstellt wird, dass jeder Mapper es sich einfach macht und solche Sachen einfach generalisiert, indem er die Flächen einfach verklebt…

Grenzmarkierungen. Die kann man mappen, sind vor Ort verifizierbar. Ziemlich einfach ist das zum Beispiel bei (Neu-) Baustellen

Nicht jeder, aber ziemlich viele. :slight_smile: Generalisieren ist ja auch nicht grundsätzlich falsch; als problematisch sehe ich es nur an, wenn es auf Kosten der Wartbarkeit und der Klarheit geht.

Auf den Spruch habe ich gewartet. :sunglasses: Du kannst nur Grenzmarkierungen mappen, die frei zugänglich sind. Es gibt aber auch Gernzmarkierungen, die nicht frei zugänglich sind, die man brauchen würde um Grundstücksgrenzen zu mappen. Und wie ich schon geschreiben habe, gibt es auch Grundstückszusammenlegungen, die Du gar nicht mitbekommst, weil die Abmarkungen bleiben die Gleichen. Nur auf der Katasterkarte ändern sich ggf. Flurstücknummern. Und das wiederum dürfen wir nicht verwenden. Deshalb mappe** ich** so etwas grundsätzlich nicht.

Deshalb sollte man das auch sehr klar und differenziert formulieren. Ich würde mich von der Formulierung im Proposal etwas eingeschüchtert fühlen.

Ich finde nichts was mich einschüchtert.

Ich beschäftige mich gerade mit einer Videoanleitung zur Bearbeitung von Multipolygonen für den Editor ID, und bin nun einigermaßen irritiert darüber, bislang lediglich eine Anleitung zum Zerstören von Multipolygonen gefunden zu haben. https://help.openstreetmap.org/questions/55984/splitting-a-multipolygon-into-two-in-id
Es ist einigermaßen absurd, anstatt den Editor ID zu reparieren, oder diesem die Fähigkeit zum Zerstören von Multipolgonen zu verbieten, die Lösung für dieses Editor Problem, in “Regeln für Multipolgone” zu suchen.

ID. ist ein Schadprogramm

ID zeigt das Verhalten eines Schadprogramms, und die Empfehlung
https://help.openstreetmap.org/questions/55984/splitting-a-multipolygon-into-two-in-id

ist sehr seltsam.

Schauen wir uns das Verhalten des Editors Go-Map!! an, so warnt dieser korrekt:
“Cnat´t extend Way, Extending a way which belongs to a Route or similar relation may damage the relation”

Solange ID. keine vergleichbare Warnung ausgibt, sollten wir die Verwendung von ID vorläufig einschränken, oder wenigstens eine offizielle Warnung ausgeben.

Wie man hier sieht,
https://wiki.openstreetmap.org/wiki/Editor_usage_stats#More_complex_analyses
gibt es Reihe von Editoren mit korrektem Verhalten, auf deren Verwendung sollten wir unter Verzicht auf den Editor ID. einstweilen verweisen.
Ich gehe davon aus, dass der relativ hohe Anteil an OSM Edits, beim Editor ID. aus HOT Aktivitäten stammt, und daher diese Statistik nicht repräsentativ ist. Probleme aus Hot Aktivitäten, sind aber sehr wohl Thema.

Das hier https://forum.openstreetmap.org/viewtopic.php?id=61207 ist eine Bekämpfung lediglich der Symptome, das Fehlverhalten des Editors ID. wohl eine der wesentlichen Ursachen für aktuelle Missing Boundaries.

edit: GoMap!! Warnmeldung + Missing Boundaries

Großes Kino hier, die Empfehlung wird jetzt schon komplizierter als die MP `s :laughing:

Yepp, war zu erwarten. :smiley:

Ich finde den Gesprächsfaden zusehends interessant, und spannend.
Wenig kompliziert wäre es, dem Editor ID. Regeln beizubringen. Zum Beispiel diesem vorläuft Edits von solchen Linien zu verwehren, welche Mitglied in einem Multipolyon sind.

Das aktuelle Phänomen, regelmäßig auftretende Lücken in Grenzen, sogenannten Missing Boundaries könnte man so wesentlich eindämmen.
Dazu wäre eine Auswertung interessant, welcher Editor am meisten beim Verursachen solcher Lücken verantwortlich ist.

@addresshistory*org Deine zwei letzten Beiträge sind off-topic. Bitte eröffne einen neuen Thread und versuche nicht, in bestehenden vom Thema abzulenken, wie du das schon im österreichischen Forum oft genug gemacht hast.

Das Lösen von Problemursachen kann restriktive Regeln überflüssig machen, sofern man mit offenen Karten spielt kann ein solcher Dialog funktionieren.

Edit: Lösen von Problemursachen/+Korrektur

Ein Einwand, der aber auch jeglicher Sachlichkeit entbehrt. Denn erstens geht es keineswegs darum, die Verwendung von Multipolygonen weitgehend zu verhindern, sondern nur darum, ihren Einsatz auf Kontexte zu beschränken, wo sie gebraucht werden. Zweitens wird das nicht mit Problemen bei ihrer Verarbeitung begründet, sondern bei ihrer Wartung durch die nächste oder übernächste Mappergeneration.

Mit Michaels Firma habe ich nichts zu tun, aber als Mapper unterstütze ich die Initiative, weil es auch mir die Arbeit erleichtert, mich beim Aktualisieren von Flächennutzungen nicht erst in ein MP-Konstrukt hineindenken und bei der Bearbeitung jedes Ways immer alle betroffenen MPs im Blick haben zu müssen.

–ks

Probleme sollten wir dort lösen, wo diese entstehen. Abstrakte Regeln in unserer OSM Wiki, werden ID. Laien und auch HOT User sicher nicht erreichen. Daher mein Vorschlag, dem Editor ID. das Bearbeiten von Multipolygonen vorläufig zu verwehren, und anschließend übrig bleibende Probleme neu zu bewerten.

Und was sind die Ursachen, das es kompliziert statt einfach gemappt wird?
Eine Fläche kann aus einem way erstellt werden.
Warum dann -zig einzelnen way’s die wiederum zu anderen Flächen gehören (können) oder noch schlimmer selbst eigene ways sind.

Ganz einfach für alle!
Wenn etwas nicht einfach dargestellt werden kann, dann eben etwas komplizierter.
Und wenn das nicht langt, kann es spezialisieren werden.

Aber die “Spezialisten” sollten dann nicht "meckern, wenn durch “einfache” Mapper Fehler erzeugt werden: Oder es sich keiner traut dort Veränderungen vorzunehmen, obwohl seit Jahren sich vieles verändert hat.

Ich denke hier kann uns nur eine Auswertung von Neis weiterhelfen.

[Mod Hut auf]

Edit: Anstößiger Text entfernt.

Unterlasse solche Unterstellungen und persönlichen Angriffe.

Ich forder Dich auf, selbigen Text umgehend selbst zu entfernen - ich räume dann die Zitate auf. Solltest Du dem nicht nachkommen droht eine Sperre.

[Mod Hut ab]

+1. So geht es mir auch.

Ich habe mir Deinen Film angesehen. Vielen Dank für die Mühe, die Du Dir gemacht hast! Das ist jedenfalls weitaus konstruktiver als die wilden Beschimpfungen und Verschwörungtheorien, die von MP-Freuden in diesem Thead (und anderswo) schon verbreitet wurden. Allerdings wird es Dich Dich traurig machen, dass Dein Film mich nicht überzeugt hat. Ich halte in diesen und ähnlichen Fällen die im hier diskutierten Proposal vorgeschlagene Arbeitsweise, die MPs auf diejenigen Fälle beschränkt, in denen sie nötig sind, immer noch sowohl für einfacher als auch für wartungsfreundlicher.

+1.

es sind nicht nur Einfriedungen oder gar nur Mauern und Zäune, wo Flächen durch Linien begrenzt werden, und diese Linien auch selbst etwas darstellen. Weitere Beispiele sind retaining walls, cliffs, Küstenlinien, cutlines, tree rows und mehr…