Landuse aufräumen und Multipolygone vermeiden

Communities Deutschland (Germany)
1

Ausgangspunkt dieses threads ist die Diskussion über die Nachteile des Detailmappings
http://forum.openstreetmap.org/viewtopic.php?id=12241
und hier insbesondere die Äußerungen des Users Weide unter #49
http://forum.openstreetmap.org/viewtopic.php?pid=162988#p162988
sowie meine eigenen Äußerungen zu Multipolygonen in verschiedenen threads und die in vielen Forumsbeiträgen erkennbare Unsicherheit im Umgang mit MP’s. Ziel dieses threads ist es, durch Vereinfachung und Eindeutigkeit bei Flächenerfassungen weitestgehend auf MP’s verzichten zu können.

Für die Überlegungen gelten folgende Prämissen:

  1. Multipolygone sind in einem offenen Projekt, dessen Datenbestand sich dynamisch durch Aktivitäten engagierter Laien mit verschiedenem Wissenstand ändert nicht trivial, fehleranfällig und pflegeaufwändig.
  2. Die zunehmende Detaillierung bei der Erfassung von Flächeneigenschaften, begünstigt durch zur Verfügung stehende hochauflösende Luftbilder, erfordert eine Erfassungsmethode, die einerseits vom Mapper noch sicher beherrschbar ist und andererseits von Auswertungsroutinen (z.B. Rederern) unzweifelhaft analysiert und dargestellt werden kann.
  3. Es ist wünschenswert, dass die simple features als offener Standard für GIS-Datenbanken in OSM beachtet werden. Deren Umsetzung ist aber bei den Regeln für Polygone und Multipolygone für Laien eher schwer machbar.
  4. Abhängigkeiten zwischen Datenbankobjekten, wie sie Multipolygone bedingen, sind möglichst zu vermeiden, da Fehleranalysen und –berichtigungen sehr zeit- und arbeitsaufwändig sind und vor allem bei Mehrfachabhängigkeiten (MP im MP, Teil-ways in anderen Relationen…) neue Fehler verursachen können.

Mein Ansatzpunkt zur Vermeidung von MP’s war, Regeln zu finden, die es Renderern ermöglichen, kleine Flächen in größeren Flächen zu erkennen, um diese dann sichtbar über die großen Flächen zu rendern. Weide setzt bei der Definition von landuse als überwiegende Nutzung von Flächen an. Ich versuche hier nun, beide Ideen zusammenzubringen.

Der Schlüssel landuse als überwiegende Nutzung ist (ähnlich wie boundary) eine eher abstrakte Flächeneigenschaft und sagt primär noch nichts über die tatsächliche Nutzung auf der Erdoberfläche aus. Dies gilt primär für die in der Wiki hinterlegten Werte brownfield, commercial, farm bzw. farmland, forest, greenfield, industrial. Military, recreation_ground, residential und ggf. auch retail. Alle anderen landuse-Werte stehen eher für eine exclusive Nutzung (basin, cemetry, reservoir…) oder sind sogar eher dem Schlüssel surface zuzuordnen (grass). Einige Werte missachten den Grundsatz der Eindeutigkeit für GIS-Datenbanken, wonach es für ein Realweltobjekt nur eine Möglichkeit der Modellierung geben darf (farm und farmland, grass und meadow). Die genannten „Unschärfen" gelten auch für viele der proposed features unter landuse.
http://wiki.openstreetmap.org/wiki/Proposed_features#Proposed_features_-_Landuse

Der Lösungsweg:
Die Werte unter landuse sind dahingehend zu bereinigen, dass in der wiki nur noch überwiegende Nutzungen genannt werden. Werte, die für eine exklusive Nutzung stehen, werden einem neuen Flächen-Schlüssel purpose, usage, utilization o.ä. zugewiesen. (Aus meiner Sicht bietet sich usage von der Verständlichkeit her am ehesten an, findet aber bei railway als Unterschlüssel für lineare Objekte Verwendung. Abhilfe würde wegen der Eindeutigkeit dort eine Umbenennung in railway_usage schaffen, da dieser vsl. seltener ist bzw. sein wird.)

Der neue Flächen-Schlüssel purpose, usage, utilization o.ä. für exklusive Nutzungen kann analog zu highway, waterway, building u.a. so ausgewertet werden, dass er über landuse in entsprechenden Zoom-Stufen abgebildet wird. Ein Ausschneiden dieser Flächen und die damit verbundene Schaffung von MP’s wird bei der Überlagerung dieser Flächenarten vermieden (auch wenn es nicht dem Standard der simple features entspricht).

Flächenausschnitte, bei denen sich Flächen des neuen Schlüssels für Exkusiv-Nutzungen überlagern, sind denkbar, beschränken sich aber vsl. auf kleine und einfach durch MP’s erfassbare Objekte, die bei Fehlern leichter zu berichtigen sind bzw. die Darstellung durch Renderer nur in kleinen Gebieten verfälschen.

Die vorgeschlagene Lösung ermöglicht es außerdem, dass die Daten für andere Systeme (mit entsprechendem Aufwand) streng nach simple features maschinell übersetzbar wären.

Inwieweit dieser Vorschlag auch für natural=* und dortige Überlagerungen sowie andere Flächentypen übertragbar ist, wäre gesondert zu diskutieren.

Ich bitte um sachliche Meinungen und Vorschläge.

2

Gute Idee: Mach mal :wink:

3

Da warte ich doch erst mal ab, was die (tatsächlichen und selbsternannten) OSM-Gurus dazu meinen :wink:
Wie kontrovers die Meinungen zu MP’s sein können, weiß ich aus anderen beiträgen :frowning:

Trotzdem: Danke für deine Meinung

4

es sollte zuerst mal eine saubere definition für das wort “überwiegend” erarbeitet werden. das ist nämlich so subjektiv wie “eine priese salz” beim kochen. deswegen kommt es ja zu den ganzen unterschiedlichen auslegungen.
und das muss hand in hand gehen mit einem proposal für alternativtags für detailmapper die, wie ich, die landuses jetzt dort eintragen wo die tatsächlichen grundstücksgrenzen erkennbar sind. erst wenn das steht, können die bestehenden microgemappten landuses konvertiert und danach der landuse wieder als große fläche darunterglegt werden.

5

Ich kann da nur für mich sprechen. Und hätte im übrigen keine Hemmungen bei mir vor der Haustür aufzuräumen wenn ich das für erforderlich hielte. Muss ich aber nicht, denn Berlin ist zumindest was OSM angeht eine echte Vorzeigehauptstadt :wink:

6

“überwiegend” sauber zu definieren ist schwierig. Ich sage jetzt einfach mal demokratisch: mehr als 50%.
Der Begriff bedeutet doch, dass innerhalb dieses Bereiches andere Flächennutzungen vorhanden sind. In einem Dorf ist der Anteil an Gärten meist höher als in einer Stadt und beide sind landuse=residential.

Deswegen wird “Priese Salz” auch nicht genau definiert, denn was dem einen schmeckt ist dem anderen versalzen und dem nächsten zu lasch :wink:

7

Kennst du das:
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=13.35233&lat=52.47438&zoom=11&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes

Neben den Warnungen gibt in Berlin leider doch noch einige MP-Fehler.

8

Überwiegend ist doch nicht schwer…das was flächenmäßig am meisten da ist. Wenn du die ganze Welt in ein polygon packen würdest, würde es natural=water bekommen :wink:

Das mit den festen Regeln ist unsinnig und macht die Bearbeitung der Daten unnötig komplex. Stell dir einen Wald mit kleinen Wiesen und Seen vor. Will ich die Waldfläche rendern oder berechnen muss ich erst den Wald zeichnen oder berechnen und dann alle Wiesen und Seen drüber malen bzw. abziehen. Geht noch, der Mehraufwand liegt darin, die passenden Polygone zu finden. Bei einem MP muss ich das nicht. Das dürften immerhin n^(n-1) isPolygoninPolygon-Abfragen sein; n=Anzahl der Polygone.

Doch was ist, wenn ich Wiesen gar nicht darstellen möchte, oder jemand noch ein ganz anderes Polygon in den Wald gemappt hat, dessen Tags ich nicht auswerte? Dann ist da Wald, wo keiner ist. Bei einem MP hab ich den Fehler nicht und es gibt auch keine sinnvolle Lösung (alle Tags auswerten ist nicht sinnvoll :wink: ), solche Fehler aufzulösen.

9

Wald (landuse=forest) ist genau das schwammige Beispiel, weil forest nun mal Wald heißt und somit Wald sein sollte. Im Sinne des landuse (überwiegende Nutzung) müsste das analog zu residential bzw. industrial eigentlich forestry oder silvicultural heißen. Zur genauen Auswertung und Flächenermittlung von “Wald” müsste man vielleicht noch einen Schlüssel forest=* erfinden :frowning:

Wald, wo keiner ist, sehe ich auch bei Flächen, die als inner ausgestanzt sind in mindestens einer Anwendung:
Mapnik zeigt:
http://www.openstreetmap.org/?lat=48.2961&lon=8.0116&zoom=14&layers=M
Reit- und Wanderkarte zeigt:
http://www.wanderreitkarte.de/index.php?lon=8.0116&lat=48.2961&zoom=14
Nop wird sicher seine Gründe haben. Und dein Ansatz setzt vrraus, dass alle MP’s, bzw. diese überlagernde Flächen fehlerfrei und vollständig als MP’s erfasst sind.

10

es braucht aber einen bemessungsradius. ansonsten definiere ich "überwiegend in einem bereich von 10x10m während ein anderer mapper bei uns in linz “überwiegend” so interpretiert hat, dass er eine große landuse fläche über eine 200000 einwohner stadt gezogen hat. beides ist per definition richtig.

11

Mit dem Vorschlag wird das Problem nicht geloest, sondern nur umbenannt:

Im Prinzip stufst du landuse von der Bedeutung her zu einer reinen Hintergrundfarbe herunter, die man eigentlich auch gleich weglassen koennte. Die Ueberlagerungsprobleme beim Detailmapping bleiben aber erhalten, nur die Schluessel davor aendern sich.

Gruss
Torsten

12

Wieso? 100% ist doch auch eine überwiegende Nutzung. Und dort, wo keine guten Luftbilder verfügbar sind, geht der Waldanteil auch runter, da mangels Möglichkeiten die Detailierung nur ungenau ist.

13

Mit zunehmender Detailtiefe kann man da keine Grenze setzen. Als z.B. Wälder überwiegend mit den yahoo-Luftbildern erfasst wurden, sah man die Lichtungen gar nicht. Heute mit bing sieht und mappt man aber auch Äcker, die in Lichtungen in Wäldern liegen. Dein Beispiel aus Linz zeigt, dass mein Vorschlag Sinn macht, denn so muss man da kein Riesen-MP basteln oder die residential-Fläche zerhacken.

14

Also nicht nur rein mathematisch ist 100% für mich ausschließliche Nutzung. Und dann gibt es da auch keine Lichtungen, und Seen drin, wodurch sich kein Notwendigkeit für ein MP ergibt :wink:

15

Mindestens bei residential und industrial ist landuse m.E. schon jetzt eine Hintergrundfarbe für ein abstraktes Objekt, aus der kein Rückschluss auf die Oberflächeneigenschaft bzw. detaillierte Nutzung möglich ist, die aber in entsprechenden Zoomstufen die Identifizierung ohne Details erleichtern soll (…nicht für Renderer…) Und warum soll mit dem neuen Schlüssel nicht gehen, was jetzt mit building, parking usw auch geht?

Edit:
und darüber hinaus versuche ich nur, deinem Rat zu folgen :wink:
http://forum.openstreetmap.org/viewtopic.php?pid=163234#p163234

16

Ich denke man kann von keinem verlangen, dass wenn er ein landuse einträgt mit Sicherheit sagen kann, dass innerhalb des Polygons nur bspw. Wohnhäuser sind. Daher hat man die Formulierung überwiegend gewählt. Der Mapper entscheidet, wie detailliert er die Polygone eintragen möchte und nimmt dann für das jeweilige Polygon die Nutzung, die überwiegt. Wenn ein anderer Mapper das detaillierter haben möchte, macht er es feiner… An diesem Prozess wird man auch nichts ändern können. Weiterhin ändert dein neues Konzept daran nichts.

Das etwas korrekt eingetragen wird, wird von jedem Ansatz vorausgesetzt.

17

Also ich weiß nicht ob der Ansatz Multipolygone durch Flächen zu ersetzen der bessere Weg ist. Mich persönlich nervt zum Beispiel wenn über einer Straße noch zwei andere Wege liegen, welche eigentlich nur ein landuse sind.
Bei Grenzen macht man es doch auch so, dass eine Grenze von zwei angrenzenden Gemeinden oder Verwaltungsbereichen genutzt werden. Und bei Flächen wollen wir das ganze neu erfinden und alles wieder in Frage stellen.
Ich bleibe bei meiner Meinung es gibt nur Punkte und Relationen. die Punkte haben die Koordinaten und die Relationen die Eigenschaften.

18

Multipolygone sind die Zusammenfassung mehrerer Polygone. Das was wir als Multypoligon bezeichnen ist oft nur ein Polygon, welches gemäß simple features durch einen äußeren und beliebige innere Ringe begrenzt wird, dessen inneres topologisch zusammenhängend ist.
http://www.slidefinder.net/g/geoinformation_iii_vorlesung/5859813 (slide18)
Diese Präsentation hat übrigens mein Grundwissen sehr erweitert.
Ich will nichts neu erfinden. Unser gesamtes Erfassungssystem ist sehr individuell und weitab von etablierten Standards, was Sinn macht, wenn man es für die nebenamtlichen OSM-Mapper nicht zu schwer machen will und kein informatik-Studium voraussetzt. In diesem Sinne will ich einen Weg suchen, der die Notwendigkeit von Multipolygonen vermeidet, wenn es irgendwie geht.

Mit deiner Meinung zu Punkten und Relationen gebe ich dir recht. Auch Flächen (Polygone) sind Punktmengen einer geschlossenen Linie, welcher eine innenliegende Eigenschaft zugeordnet wird

19

Also wenn ich mir die Wiki anschaue, dann finde ich zu Mulitpolygon: http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon#Mehrere_Wege_bilden_einen_Ring

Und genau dieses Feature schätze ich an den Multipolygonen. Ich benutze also immer vorhandene Wege oder lege Eigenschaftslose Wege zwischen zwei verschiedenen landuse=* an, welche dann von beiden benutzt werden. alternativ kann ich auch mehrere Wege übereinander legen und dann lassen die sich auch wieder schwer bearbeiten.
Jedenfalls waren dies meine Erfahrungen als Anfänger. Da habe ich erst mal Straßen verlegt, damit ich die vernünftig bearbeiten kann. Das geht eigentlich auch nur dann, wenn der Ersteller der Fläche nicht jeden Punkt der Straße auch als Bestandteil der Fläche ausgewählt hat.

20

Also ich habe zu dem Vorschlag eine Frage:
Wir haben ein normales äusseres Polygon (nehmen wir mal landuse residential) und mehrere Inner-Polygone. Eines davon ist ein großer Acker, den der Bauer einfach nicht als Bauland verkaufen will und dann noch ein paar Spielplätze.
Wie kann ich nach Deinem Vorschlag sagen, dass der Acker nicht zur Residential Fläche zählt, die Spielplätze aber schon?
Wenn ich den GIS Vorschlag richtig verstehe, wird jedes innere Polygon aus dem Aussenpolygon ausgeschnitten. Somit müsste ich bei jedem Haus, Spielplatz, etc im inneren Polygon wieder die residential Eigenschaft ergänzen um zu seigen, dass dort auch ein Wohngebiet ist