Hallo,
kann man mir mal den Sinn dieser Multipolygone erklären.
https://www.openstreetmap.org/relation/3862914 - für einen Acker.
https://www.openstreetmap.org/relation/3862913#map=15/50.9134/6.3810&layers=N - für ein Industiegebiet mit zwei Außenlinien (die man Zusammenfassen könnte) ohne weitere Inhalte. Reicht da nicht ein landuse=industrial vollkommen aus?
Gruß
Fortgeschrittene Multipolygonitis. Ein Teil des Ackerrandes ist auch Teil des angrenzenden industrial https://www.openstreetmap.org/relation/3862913, der andere nicht, also braucht der Acker zwei separate Außengrenzen, also muss auch der Acker als MP definiert werden.
Diese Art des Flächenmappings, wo jede Grenzlinie nur einmal eingetragen und dann allen fraglichen MPs zugewiesen wird, hat zwar einige Vorteile (es geht wirklich schnell, keine aufeinanderliegenden Ways, daher ist jeder leicht selektierbar), aber wer so was nur ein einziges Mal nachträglich bearbeitet hat, weiß, dass die Medaille noch eine andere Seite hat 
–ks, der in seiner Anfangszeit auch mal so gemappt hat
Hallo Kreuzschnabel,
o.k. verstanden. Über den Sinn kann man sicherlich streiten.
Dann schau dir bitte auch mal diese Fehlermeldung an https://www.openstreetmap.org/note/1323602.
Ich sehe in JOSM beim besten Willen keinen Fehler.
Gruß
In der ÖPNV-Karte sehe ich auch keinen Fehler: https://www.xn–pnvkarte-m4a.de/#6.3761;50.9155;16
Scheint zwischenzeitlich repariert worden zu sein, ohne die Note zu schließen. Kannst du zumachen.
–ks
Hallo,
das ist kurzsichtige, scheinbare Optimierung. Kreuzschnabel hat schon den wertenden Begriff der Multipolygonitis genannt. Such mal nach “Multipolygonwahnsinn”.
<Multipolygonbefürworter meine_Meinung=“nein”>
Damit kann man im OSM-Datenmodell angeben, dass zwei aneinander grenzende Flächen eine gemeinsame Kante habe. Beide Relationen vom Typ Multipolygon referenzieren ja denselben Way. Außerdem werden unnötige Ways gespart, weil man den einen Way mehrfach verwenden kann.
</Multipolygonbefürworter>
Davon habe ich mich in meinen ersten Monaten (AFAIR sogar im ersten Änderungssatz) verführen lassen.
Mit Potlatch 2 soll das angeblich besonders effizient zu editieren sein. Diesen Editor hat zumindest ein Multipolygonliebhaber verwendet, dem wir es auf schmerzhafte Art abgewöhnen mussten. Er hatte argumentiert, dass es doch so einfach sei. Vielleicht muss man dazu aber auch in besonders hohe Potlatch2-Sphären aufgestiegen sein. 
Mir als JOSM-Nutzer werden sie verwehrt bleiben.
Weitere Argumente für die intensiv(st)e Verwendung von Multipolygonen nennt dir sicherlich er hier auf der Mailingliste Talk-de (die drei letzten Absätze, er ist auch dort eher allein mit seiner Meinung)
Die Realität ist leider, dass man mit diesem Mapping sich elektrische Dornenhecken in sein Mappingrevier pflanzen kann, an die sich Leute, die keine absolute Anfänger mehr sind, nicht oder nur widerwillig herantrauen. Absolute Anfänger wissen noch nicht was sie tun und treten die elektrischen Dornenhecken um. Mangels Schmerzempfinden (kennen ja noch kein Qualitätssicherungswerkzeug wie den OSM Inspector oder Osmose) fällt ihnen nicht auf, dass ihre Bearbeitungen unabsichtlich das Multipolygon beschädigt haben.
Ebenfalls Realität ist, dass für zahlreiche Anwendungen von OSM-Daten Multipolygone, die man mit geschlossenen Ways (das Beispiel, das du genannt hast) ebenso gut und einfacher mappen könnte, bremsend wirken.
In OSM haben nur Nodes Koordinaten. Ways haben nur die IDs der Nodes, aus denen sie bestehen (die sie referenzieren). Relationen haben ebenfalls nur ID-Listen (plus Objekttyp des Mitglieds und dessen Rolle).
Die wohl häufigste Anwendungsarten von OSM überführen als erstes OSM-Daten in eine Struktur, in der es keine Nodes, Ways und Relations mehr gibt. Stattdessen gibt es Punkte, Linien und Flächen (Point, LineString, Polygon und dazu noch MultiPoint, MultiLineString, …, aber das geht hier zu weit). Ein LineString ist eine Liste an Koordinatenpaaren (eine Dezimalzahl für den Rechtswert, eine für den Hochwert), womit die Geometrie beschrieben wird. Bei Polygonen ist es ebenso.
In OSM-Dateien stehen am Anfang alle Nodes nach ID geordnet, dann alle Ways nach ID geordnet und am Ende alle Relationen nach ID geordnet. Um aus Ways LineStrings zu machen, muss man zuerst alle Nodes in den Arbeitsspeicher laden (~ 40 GB für den gesamten Planet, Tendenz steigend), denn nur beim Zwischenspeichern im Arbeitsspeicher kann man in akzeptabler Zeit LineStrings erzeugen. Dennoch – und genau darin liegt der Vorteil – von Ways, genügt es nur die Nodes im Arbeitsspeicher zwischenzuspeichern. Ein einziges Einlesen der OSM-Datei, das ob der Datenmenge schon ein paar Minuten mit gut optimiertem Code und mehreren parallelen Threads dauert, genügt.
Für das Rekonstruieren eines Polygons aus einer Multipolygon-Relation muss man die OSM-Datei zweimal einlesen. Erst liest man alle Nodes ein und speichert ihre Koordinaten im Arbeitsspeicher. Anschließend geht man flott über die Ways hinweg (man muss ein bisschen lesen, wenn es PBF-Dateien sind) und liest die Relationen ein. Jede Relation, die man für interessant erachtet (type=multipolygon), speichert man ebenfalls im Arbeitsspeicher zwischen. Man legt für sie eine Liste der Mitglieder (Typ, ID) an. Nun springt man wieder an den Anfang der Datei und sammelt alle Mitglieder (Nodes, Ways, andere Relationen) ein. Wenn eine Relation vollständig ist, kann man sie erst rekonstruieren und den Speicher anschließend wieder freigeben.
Das ist machbar, wenn es eine relativ zur Gesamtzahl an flächenhaften Objekten in OSM geringe Anzahl an Multipolygonrelationen ist. Wäre aber jedes Gebäude als Relation vom Typ Multipolygon erfasst, müsste man alle Nodes und Ways zwischenspeichern (man würde aber dann nur einmal die Datei lesen müssen) und erheblich mehr Arbeitsspeicher benötigen.
So viel zu dem Datenmodell, das den Datennutzern auf die Füße fällt, sie zum Kauf bzw. zur Miete teurer Server zwingt und keinem nützt. Glücklicherweise bewegt sich etwas mittlerweile ein klein wenig an der Front.
Ernsthafte Anwendungen samt Quellcode, für die der Vorteil der gemeinsamen Kante und des Sparen von Ways einen Vorteil bringt, sind mir bislang nicht bekannt. Vielleicht sollte ich mal einen symbolischen Preis dafür ausloben?
Viele Grüße
Michael
Wahrscheinlich ist hier die Darstellung im ÖPNV-Layer (Verkehrskarte) gemeint.
https://www.openstreetmap.org/way/515704422#map=18/50.91445/6.37610&layers=TN
Dort fehlen zwei Straßenabschnitte in der Darstellung.
https://www.openstreetmap.org/way/515704422
und
Auch in JOSM ist es recht einfach. Du zeichnest erst alle Grenzlinien in die Fläche ein. Bloße Flächengrenzen brauchen kein Tagging, bestehende Ways (Straßen …) werden überall da aufgeteilt, wo neue Grenzlinien auf sie treffen. Im zweiten Arbeitsgang selektierst du für jede Einzelfläche die Grenzlinien, drückst Strg-B, Tagging dran, fertig ist das MP. Der Zeitvorteil liegt darin, dass jede Grenze nur einmal Punkt für Punkt abgefahren wird. Macht man dagegen für jede Fläche ein Polygon, muss man auch jeden schon gemappten Grenz-Way Punkt für Punkt nochmals abklicken. Bei komplexen Gebilden mit vielen Verzweigungen bringt auch die „Follow“-Funktion von JOSM da keinen großen Zeitvorteil.
–ks
Dann ist die Verkehrskarte im Rendering aber fürchterbar hinterher. https://www.openstreetmap.org/way/515704421 ist seit 9 Monaten drin und in allen fraglichen Relationen Mitglied.
Ich sehe keinen Handlungsbedarf auf Mappingseite.
–ks
Danke an euch beide für die Erläuterungen.
Keine Sorge Michael. Habe 30 Jahre in der IT, größerer Systemhäuser gearbeitet. Kenne mich daher mit Hard- , Softwareentwicklung, Datenbanken usw. aus, auch wenn ich als Rentner vielleicht nicht mehr so ganz auf dem aktuellen Stand bin.
Danke