Multipolygonwahnsinn - oder: Durchblick war gestern!

Finde ich gut.

Ich würde noch anregen, darauf hinzuweisen, dass sich Multipolygone oft vermeiden lassen, indem Flächen kleinteiliger eingetragen werden. Dass also beispielsweise nicht 50 Quadratkilometer mit einer einzigen, großen Acker- oder Wiesen-Fläche überdeckt werden, was wegen der unvermeidlichen Inseln ein Multipolygon zwingend macht. Stattdessen kann man kleinere Gebiete als simple Flächen eintragen, die auch durchaus direkt aneinander grenzen dürfen. Auch bei Wohngebieten und dergleichen lassen sich MPs auf diese Weise oft vermeiden.

Ich denke mal da liegt dann wohl auch das Hauptproblem. Mir ist nicht erst einmal aufgefallen das sich die unterschiedlichen Übersetzungen zum Teil recht deutlich unterscheiden. Deshalb lasse ich inzwischen die Übersetzungen vollkommen links liegen und nutze nur noch das englische Original.

Ansonsten finde ich die im ersten Post aufgeführten Multipolygon Relationen aber auch nicht so schwer als Mensch zu verstehen. Selbst ohne Software kann man da recht gut erkennen was der Mappe wollte. Für Software ist eine Multipolygon Relation in meinen Augen auch sehr gut aus wert bar.

Nun ja, dein Bauplan funktioniert aber nur, weil dein Gehirn die Arbeit übernimmt, aus den Linien die Zimmer zusammenzusetzen. In einer Datenbank, sei es für einen Gebäudeplan oder in OSM, musst du das schon exakt definieren.

Um deine Analogie also weiterzuspinnen: Du gibst jeder deiner einfach eingezeichneten Linien eine Nummer. Dann nimmst du ein zusätzliches Blatt zur Hand und erstellst dort Tabellen, auf denen verzeichnet ist, dass die Mauern 1, 4, 5 und 7 die Küche bilden usw. Auf dem eigentlichen Bauplan ist nicht eingezeichnet, zu welchen Zimmern eine Mauer gehört. Das erfährt der Maurer nur dadurch, dass er die Tabelle auf dem Beiblatt auswertet.

So viel simpler und logischer erscheint mir das nicht.

Solche Extremfälle kannst du natürlich konstruieren, und die sind tatsächlich unschön. Aber erstens: Wie oft kommen die tatsächlich vor? Zweitens sollen Relationen ja nicht verboten werden, es besteht doch sicherlich Einigkeit, dass sie für Gebilde wie Grenzen sinnvoll sind. Damit fallen schon einige deiner 7 Linien weg. Wenn dich das Überlagern mehrerer Linien stört (ich mag das auch nicht), kannst du drittens etwas Mikromapping betreiben und Wald- sowie Wiesengrenze von der Bachmitte trennen und an den Bachrand legen. Dann hast du drei getrennte Linien - was zugegebenermaßen andere Nachteile hat, aber du musst halt die Methode wählen, die dir am besten gefällt.

Dazu ein Denkanstoß, vielleicht stimmt er dich ja ein wenig milder: Linien sind in OSM eigentlich auch ein logisches Konstrukt, die Relationen gar nicht so unähnlich sind. Sie definieren sich nämlich dadurch, dass sie über Punkte laufen. Und wenn zwei Linien über dieselben Punkte laufen, ist das doch nicht so ein konzeptioneller Unterschied gegenüber zwei Relationen, die das dasselbe Linienstück verwenden.

Hallo Zusammen,

unnötig unübersichtlich und kompliziert werden Multipolygone für mich, wenn dafür vorhandene Wege und Flächen verhackstückt werden.
Da braucht einer für sein MP hier ein Stück Weg, dort einen Waldrand und da einen Teil eines Baches oder eines Ortsgebiets. Das Ergebnis
ist, dass durchgehende Wege zerteilt und bereits vorhandene Flächen ebenfalls zu MP gemacht werden müssen, um sie wieder
zusammenzufügen. Je detaillierter das Mapping, um so kleiner werden die einzelnen Teilstücke.

Grüße

Ich wohne in Kufstein und bin auch in diesem Bereich tätig. Hier sind folgende Grenzbereiche vorhanden:

Deutschland/Österreich
Bayern/Tirol
Landkreis Rosenheim/Bezirkshauptmannschaft Kufstein
Tirol/Salzburg
Kufstein/andere Bezirkshauptmannschaften

um nur ein paar zu nennen :smiley:

Du musst mich nicht milder stimmen, denn das meiste von dem was ich schreibe ist nur ziemlich direkt und manchmal etwas forsch formuliert, trifft aber das was ich meine :wink:

Das beim Menschen das Gehirn das Zusammensetzen übernimmt ist mir klar und das man das Zusammensetzen einem PC erst beibringen muss ist richtig. Nur funktioniert das bei OSM ja schon hervorragend. Warum also nicht verwenden?

Ich befürworte die Verwendung von MP´s, denn wie mein Chef immer sagt, ich denke gerne akstrakt.
Und das ist bei MP´s von großem Vorteil, denn nichts anderes wird durch sie erreicht, wir abstrahieren die Infos.

Strecken mit Wegen als Teile einzelner Multipolygone werden auch für Routingprogramme und Firmware immer schwerer zu berechnen, da die IDs der einzelnen Abschnitte häufiger wechseln. Das äußert sich dann bei langen Touren in zeitigeren Routenberechnungsabbrüchen - oder in unverstandenen Umwegen, weil längere Streckenabschnitte gleichbleibender ID und somit weniger IDs über die Gesamtstrecke besser beherrschbar sind.

Grüße
Mario

Das Teil war ja schon faul. Wenn ich da was falsch gemacht habe, hätte man mich (auch hier) darauf hinweisen können.
Andererseits kontrolliere ich Änderung, die auf dem OSMI beruhen meistens hinterher in demselben. War hier nicht mehr möglich.

BTW, Danke an die Putzfrau.

Ich denke das würde dann langsam den Rahmen der Seite sprengen, die eigentlich ja definieren sollte, was ein Multipoly ist. Da müßte man dann weiter ausholen und eine Art Best-Practice Seite aufmachen, für den detaillierten Umgang mit Flächen und den häufigsten Usecases.

Eigentlich sind die IMHO anzustrebenden Grundregeln sehr einfach:

  1. So einfach strukturieren wie möglich, immer an Mapper ohne technische Ausbildung denken
  2. Keine bestehenden Tags mißbrauchen/umdefinieren

Was großflächige Objekte angeht, halte ich persönlich den aktuellen Multipolygon-Relation-Ansatz auch technisch für ungeschickt. Er versucht halt als Kompromiß mit vorhandenen Mitteln etwas auszudrücken, wofür die vorhandenen Mittel nie vorgesehen waren.

Als technische Lösung könnte ich mir eher vorstellen

  • entweder ein echtes API-Objekt für solche Flächen, so daß man direkt damit arbeiten kann und nicht immer alle Relationen durchsuchen muß bevor man weiß ob ein Way allein gültig ist oder nur Einzelteil einer Multipoly-Relation. Einen entsprechenden Vorschlag hab ich schon lange auf der API0.7 Seite eingetragen.

  • eine additive Multipoly-Relation, die übersichtlicher und weniger empfindlich gegen Fehler ist. Die Idee wäre, ein Multipolygon aus vielen Einzelpolygonen zusammenzubauen, von denen aber jedes für sich ein geschlossenes, gültiges Teilgebiet beschreibt (anstatt aus einzelnen Linienstücken, die jedes für sich sinnlos sind). Mit der Relation könnte man ebenso das Gesamtobjekt konstruieren, indem man die gemeinsamen Kanten entfernt. Aber ohne die Relation oder ohne Verständnis der komplexen Gesamtlage würde jedes Einzelpolygon immer noch in jedem Editor sichtbar, in jeder Karte angezeigt und von jedem Mapper verstanden und editiert werden können.

  • Den Mechanismus für die Abbildung von Löchern halte ich für verständlich, solange die Löcher auch wieder einfache, geschlossene Polygone sind. In vielen Fällen wären die Löcher bei einem additiven Ansatz aber auch komplett überflüssig, da man ja die Loch-Gegend mit mehreren Polygonen umgeben kann, die per Relation zu einer Einheit definiert werden. Dann ist kein Ausstanzen mehr nötig.

bye
Nop

Dann denke mal zurück, was Du teilweise für einen Mist produziert hattest.
Du beschwerst Dich ab und an über nicht vorhandenes Detailmapping. Da frage ich mich, weshalb manche Flächen die Du angefaßt hast, laut Bing danach genau so ungenau waren wie davor.

Also ich probier es mal mit Handfesten Argumenten und weniger Emotionen.

Hier ist eine Gegend, in der ca 100km^2 mit je EINER farmland, meadow und forrest Relation abgedeckt sind: http://www.openstreetmap.org/browse/relation/1918945

Versuche dort in der Gegend mal irgend etwas zu machen, um ein Gespür dafür zu bekommen. Ich habe frustriert aufgegeben!

PRO MP:

  • Redundanzvermeidung. Jede Grenzlinie nur 1x zeichnen, statt sie nachziehen zu müssen (und dabei womöglich einzelne Nodes zu übersehen).

KONTRA MP:

  • Ein kleiner Fehler und die Zuordnung innen/aussen schlägt fehl. 100km^2 Wald, Wiesen oder Felder verschwinden.
  • JOSM (und alle anderen Tools) versagen bei der zuordnung von innen/aussen, wenn sich nicht die GANZEN Relationen heruntergeladen haben. Versuche mal die Relationen der obrigen Region vollständig heruterzuladen.
  • Wenn man eine Kleinigkeit an einer Relation ändert, muss der Renderer die gesamte Relation neu zeichnen. Im obrigen Beispiel sind das jeweils 100km^2.
  • Das herunterladen der Relation 1918945 bricht bei mir in JOSM häufig mit einem Timeout Fehler ab. (mit “Download object”)
  • Es wird immens viel Platz verbraucht, da bei jeder kleinen Änderung die komplette Relation neu gespeichert wird. Die Relation hat etwa 360 Versionen mit je 1500 Wegen.
  • Es treten Probleme beim Schneiden auf, wenn nicht alle Teilstücke der Relation enthalten sind. Dann fehlen z.B. plätzlich Wälder auf Garmin.
  • Unerfahrene Mapper bauen schnell Fehler ein, die mit viel Aufwand nachbearbeitet werden müssen.
  • Eine Verfeinerung von einmal mit MP gemappten Gebieten ist mühselig und fehleranfällig.
  • Selbst erfahre Mapper meiden solche Gegenen. Zumindestens ich tu mir so etwas nicht an - da gibt es genug anddere Gegenden, die die auch auf Bearbeitung warten.
  • Wege werden unnötig oft zerschnibbelt und müssen vor der Verwendung in Routern und Renderer erst wieder zusammengesetzt werden.

Das Argument “Speicherplatz” habe ich nicht zugeordnet, da die zusätzlichen Wege und Relationen die Einspaarung durch weniger Refferenzen vermutlich mehr als zunichte machen.

Hat noch jemand Argumente für diese Liste, so dass man danach eine sachliche Diskussion starten kann?

Ja, die deutsche Version sollte eine Übersetzung der englischen sein, mehr nicht. Verbesserungen bitte immer erst in die englische Version einbringen. Ausnahmen sind sprach- oder länderspezifische Eigenheiten, z.B. habe ich auf de:access ein paar Anmerkungen zu Mopeds/Motorfahrrädern gemacht, weil eine 1:1-Übersetzung irreführend wäre.

Gar nichts halte ich davon, Empfehlungen für oder gegen komplexe MP ins Wiki reinzuschreiben. Denn darüber herrscht kein Konsens. Vielmehr sollte reingeschrieben werden, dass (bzw. in welchen Fällen) das ein Streitthema ist, und was die Pros und Contras sind.

Nun, mein Vater war Architekt. Um ein Haus zu bauen brauchst du Pläne für den Maurer, den Zimmermann, Elktriker, Installateur etc. Jeder bekommt seinen eigenen individuellen Plan. In der Zeit vor CAD und Plotter wurden die Pläne also manuell mit durchpausen jeweils von Hand gezeichnet. Dabei enthielt jeder der Pläne allgemeine Dinge (z.B. Mauern) und wurde danach um spezifische Informationen ergänzt.

Nach deiner Logik müsste man aber die Umrisse der Mauern nicht noch mal zeichnen, denn der Elektriker kann sich diese Informationen ja aus dem Plan der Mauerer holen. Auch in OSM gibt es ja relativ unabhänige “Pläne” mit Grenzen, Landnutzung und Strassen.

Andersherum kann man es auch sehen: Nach deiner Logik zeichnen Elektriker, Maurer, usw. ihre eigenen Mauern und stehen anschließend mit unterschiedlichen Maßen da.

Ich bin auch der Meinung, vorhandene Wege für MPs zu nutzen. MPs mit gemeinsamen Grenzen sind übersichtlicher und weniger fehleranfällig als 3 übereinander liegende Wege bzw. Flächen.

Pro MP:

  • Laufen mehrere Linien übereinander, ist es im Editor schwieriger, die gewünschte auszuwählen.

Contra MP:

  • Das Auftrennen großer MPs, um sie bspw. in zwei Hälften zu zerlegen, ist sehr aufwendig. Während die outer-Elemente noch leicht aufzutrennen sind, ist das Neuverteilen der inner-Elemente sehr mühsam.
  • Solche farmland- und meadow-MPs spiegeln falsche Tatsachen wider: Die darin zusammengefassten Acker- oder Wiesenflächen haben nichts miteinander zu tun, das MP wird allein als “Farbrolle” missbraucht.
  • Mapper vergessen oder merken oft gar nicht, dass neu eingetragene Flächen innerhalb eines MP liegen und ausgeschnitten werden müssten (Bauernhof als Insel im Acker usw.) QA-Tools wie der OSM Inspector machen auf solche Fehler nicht aufmerksam, da sie nur die Relationsmitglieder auswerten.

Fairerweise muss ich noch sagen, dass einige deiner Argumente nur gegen so riesige MPs wie in deinem Beispiel sprechen, nicht gegen das Konzept an sich. Sollte man vielleicht sorgfältiger trennen.

Ich möchte dieses Thema an sich hier NICHT reinziehen und darüber diskutieren, aber ganz übel wird es, wenn ein complex-Multipolygon-Liebhaber gleichzeitig ein Landuse-an-Straßen-Kleber ist. Dann sind die Straßen zigfach gesplittet und gleichzeitig Teil mehrerer Multipolygone. Ich hatte schonmal einen Fall, wo die Straßen zigfach gesplittet wurden und jeder kleine Parkplatz (1-5 Plätze) und jede kleine Grünfläche im Wohngebiet als MP erstellt wurde. Da sich der betreffende Mapper allerdings entschieden hat, keine CT-Entscheidung zu treffen (wohl mal wieder ein “spezieller” Mapper…), habe ich das alles gelöscht und in einfacher Form neu erstellt, die Straßennamen waren zum Glück “sauber” von einem Zustimmer vorhanden. Wer dann da etwas ändern will, der hat wirklich seinen Spaß im Relation-Dschungel. Und da kann dann natürlich auch einiges kaputtgehen.

Wenigstens einen Vorteil hat das allerdings gegenüber der anderen (und von mir genauso gehassten, aber - anderes Thema) Lösung, bei der “simple” Polygone direkt auf den Straßen kleben: man trifft immerhin die Straße sofort und muss sich nicht erst durch zig andere ways wühlen und ggf. ungluen.

Ich bin auch dafür, die Strukturen möglichst einfach zu halten, also MPs nur dort, wo es sein muss. Für mich sind das nur “gelöcherte” Flächen. Grenzen sind für mich etwas eigenständiges und keine klassischen Multipolygone und sollten hier rausgehalten werden. Zumal die meisten Grenzen völlig losgelöst von “realen” Objekten existieren - nur weil der Wald teilweise gerodet oder der Fluss begradigt wurde, läuft die Grenze nicht automatisch anders.

Es gibt genügend Prüftools, außerdem schaut man sich Änderungen eh nachher in Mapnik an und dann fällt ein Fehler gleich auf. Ich finde es sogar gut, wenn ein Fehler auffällt. Wenn man beim Nachzeichnen von Linien einen Fehler macht, bleibt der Fehler jahrelang drin und nachher weiß man nicht mal, ob das mit Absicht so gezeichnet wurde.

Solche Performanceprobleme gehen gehen null, weil die Systeme immer leistungsfähiger werden.

Siehe oben. Obwohl der Datenbestand immer umfangreicher wird, ist Mapnik immer schneller geworden.

So große Relationen sollte man aufteilen. Nicht wegen Speicherplatz, sondern wegen Übersichtlichkeit.

Hört sich nach SW-Bug an.

Das tun sie sowieso, egal wie man die Daten erfasst.

Darüber kann man streiten.

Wege werden sowieso zerschnibbellt: für Brücken, maxspeed- und tracktypeänderungen, neuerdings auch für Spurmapping… Darum sehe ich das Problem eher umgekehrt: Die vielen kurzen Straßenstücke als Grenzabschnitte machen das MP unübersichtlich. In beiden Fällen ziehe die Straßen gern 1x für die MP-Grenze nach. Das ist ein Kompromiss: Straßen und Flächen beeinträchtigen einander nicht, und man muss die Straßen nicht mehrmals nachzeichnen, sondern nur 1x.

Das größte Problem, wenn man mit vielen MP arbeitet, und das hast du gar nicht gelistet, ist vielleicht, dass man dann im Editor eine lange Liste an Relationen hat. Da ist kaum mehr zu sehen, was was ist. Aber das ist ein Problem von Relationen generell.

Auch das ist eine Frage der Größe.

Bei administrativen Grenzen ist das absolut sinnvoll, weil entweder jeder Weg eine eigene Bedeutung hat (Straßenmitte, Eisenbahn, Fluß/Bach, …) oder nur eine Grenze ist (kann man mit boundary=administrative am Weg kennzeichnen). ALs Grenze gehört ein Weg jedoch zu mindestens zwei Gebieten.

Bei Häusern an Häusern jedoch würde es einen erheblichen Mehraufwand bedeuten, Außenwände und Zwischenwände einzeln zu zeichnen und für jedes Haus noch eine passende Relation zu erzeugen. Aus dem Grund wird das auch kaum gemacht.

Ich denke (wie schon von anderen angemerkt), dass man großflächige Objekte (mehrere zig Quadrat-Kilometer) und kleinflächige Objekte (z.B. Häuser an Häuser) getrennt betrachten sollte.

Wenn man, wie im Wiki vorgeschlagen, die Taggs an die Relation macht (unabdingbar bei mehreren Wegen für einen outer-Ring), dann hat man das Problem, dass nicht mehr unmittelbar erkennbar ist, um was für ein Objekt es sich handelt.

Edbert (EvanE)

Das Problem besteht bei “nomalen” Flächen auch, spricht also nicht gegen MPs.

Ich sehe das Problem nicht.

Zeichne ich den Bauernhof direkt auf das Feld, wird es auch von keinem Tool bemängelt, obwohl es falsch ist. Also ist das kein Grund gegen MPs.

Das Aufsplitten des äusseren Weges ist mit und ohne MP nötig.

Bei MPs kommt jetzt noch das Kopieren der Relation und das manuelle umsortieren der Wege zu den zugehörigen Relationen dazu.

Ohne MP (bzw auch bei MPs, deren outer aus einem Weg besteht) gibt es eine super Hilfe: utilsplugin2 “Split Object”. Zwei Punkte und eventuell noch den zugehörigen Weg selektieren. “Split” (Alt-X). Fertig (Tags werden mit kopiert)

Willst du deinen Beitrag eventuell noch einmal überdenken und gegebenenfalls korrigieren? Analog zur Meinung von “mdk” steigt auch in meiner kleinen Welt die Anzahl der Fehler mit wachsender Komplexität der Aufgabe. Das ist dann der Grund, warum die erste praktische Fahrstunde auf einem Parkplatz oder Privatgelände beginnt.

Die laxe Art, mit der du m. E. fundierte Argumente “abbügelst” lässt jetzt nicht gerade eine grosse Bereitschaft, Argumente des Gegenübers auch Ernst zu nehmen, erkennen.

Gruss Christian