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

Ich habe das Gefühl, hier wird das Pferd von hinten aufgezäumt. Eine Mauer oder eine Säule mappt man dort, wo sie ist, wo sonst?
Ob ich jetzt für eine Flächengrenze die vorhandene Mauer wiederverwende oder nicht ist doch eine andere Frage.
Umgekehrt, falls zuerst die Fläche erfasst wurde, und ich jetzt eine Mauer hinzufügen möchte, dann muss ich überlegen, ob die Mauer evtl. die Punkte der Fläche wiederverwendet oder neue braucht.

Hier noch paar Sachen die mir ein-/aufgefallen sind.

=> eventuell den Punkt 5. erweitern, (hinsichtlich eines direkten Verantwortungsprinzips) sodass sich die Hilfesuchenden bevor sie die derzeit aufgezählten Anlaufstellen wählen, sich zuerst beim verantwortlichen MP-Ersteller per PN (oder im CS) melden
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen#Proposal
“Falls du unbeherrschbare MPs vorfindest und zweifelst, ob du …”

=> Sortierung:
Da, die Sortierung der Punkte von Beweggründe derzeit mit den beiden Punkten beginnen in denen es hauptsächlich um die Neumapper geht

  1. *"Unabhängig vom Editor wollen wir es allen Mappern … " *
  2. "Es fällt nicht nur Neulingen, sondern … "
    https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen#Beweggr.C3.BCnde
    könnten auch die Informationen unter Proposal (1.-6.) danach sortiert werden.
    Daher eventuell den Punkt bei dem es zunächst mal um die Neumapper geht (derzeit 5. "Falls du unbeherrschbare MP … " ) nach oben ziehen (als Punkt 1.).
    https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen#Proposal

=> die Beispiele (239022783 & 2337327) ggf. auf die aktuelle Objektversion fixieren (bekommt man das mit der overpass-turbo +date Funktion hin?)
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen#Beispiele

=> vorzeitige Erwähnung der potentiellen Konsequenzen für Mitgliedskollegen, die der Empfehlung / dem Leitfaden nicht folgen
Abschnitt? ggf. neu anlegen?

Nebenbei, was ist hier:
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen#Kommentare
damit
" Der Proposal enthält keinerlei Begründung, warum …"
gemeint?

Danke für die Doku’, werde ich mir bei Gelegenheit ansehen.

Ich nutze den JOSM-Editor eher selten, könntest Du auch eine Anleitung für den iD-Editor erstellen?
Vielleicht könnten dann beide Verweise zu den Anleitungen mit ins Proposal aufgenommen werden. :slight_smile:

Hallo,

Entschuldigung, dass ich einen unvollständigen Text abgesendet habe. Es sollte heißen:

"Zum Verkleben mit Verkehrswegen sollte das Proposal IMHO nichts sagen, sondern das einem anderen Vorschlag überlassen. Grundsatz: Ein Proposal – ein Thema. Frederiks Vorschlag zum Verkleben von Verkehrswegen und Straßen trifft ja zu Multipolygonen vs. geschlossenen Ways und einfachen Multipolygonen vs. komplizierter Multipolygone auch keine Aussage. Ich schätze Frederik so ein, dass er nichts dagegen hat, wenn sich seines Textes annimmt und ihn zur Abstimmung bringt.

Ich stimme dir zu, dass die Regel weich sein sollte. “Sollten nicht” ist aber weicher als “dürfen nicht”. Zumindest ist das mein Verständnis. Man möge meine Deutsch-Kenntnisse korrigieren, falls ich da falsch liege.

Viele Grüße

Michael

Abgeshen davon, dass ich mich bei meinem Post vertippt habe und Säulen statt Zäune geschrieben habe bringst Du es auf den Punkt. Im Proposal ist es aber sehr schwammig formuliert und unterstellt aber, dass der Mapper es mit Absicht falsch mappt.
Deshalb: Was “on the ground” so ist, wird auch so gemappt.

So richtig verstehe ich nicht was Du damit meinst. Wenn im Gelände (“on the ground”) ein Fläche am Zaun endet, dann gehört der Zaun auch dorthin. Der Begriff Grenze, den Du hier einführst, ist missverständlich. Das Ende einer Fläche ist eine optische Abgrenzung und wenn da ein Zaun steht, wird er dort eingezeichnet. Wenn das zufällig auch die Grundstücksgrenze ist OK. Ich persönlich werde aber keine Grundstücksgrenze als solche mappen, weil sie von den Flächenbegrenzungen abweichen kann, wir keine Katasterkarte sind und sich solche Grenzen unbemerkt von der Öffentlichkeit durch Grundstückszusammenlegungen bzw. -teilungen ändern können. Außerdem kenne ich keine Quelle, die OSM konform ist, aus denen wir Grundstücksgrenzen ziehen könnten. Das Einfriedungen Grenzabstände einhalten müssen, wäre mir neu. Deshalb wäre selbst wenn, wir die Grundstücksgrenzen aus zulässigen Quellen hätten, ein willkürliches Setzen eines Zaunes auf die Grundstücksgrenzen zum Zwecke der Vereinfachung unzulässig.

In Thüringen zumindest können Einfriedungen direkt auf die Grenze gesetzt werden (Hecken natürlich nicht). Deshalb hilft auch hier, die Einhaltung der “on the ground Regel” :slight_smile:

@aeonesa: im Grunde sind wir uns weitgehend einig. Aber auch in Thüringen ist zu landwirtschaftlich genutzten Flächen ein Grenzabstand von 50cm einzuhalten.
Konstruiertes Beispiel: Ist die Weide/Koppel mit einem Zaun eingefriedet, dann kann oder sollter der Zaun direkt auf die Grenze des meadow gesetzt werden. Der gleiche Zaun begrenzt aber eben nicht gleichzeitig den daneben liegenden Acker. Zu diesem muss ein Abstand eingehalten werden. Anders gesagt, der Bauer kann nicht bis unmittelbar bis an den Zaun pflügen, da geht technisch wie rechtlich nicht. Kein Zaun an Ackerflächen. Deshalb: reiflich überlegen, wie ich eine Einfriedung mappe.

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.