Landuse aufräumen und Multipolygone vermeiden

Communities Deutschland (Germany)
41

Für mich ergibt sich aus der bisherigen Diskussion folgender Stand:

  1. Es gibt gute Gründe dafür, Multipolygone grundsätzlich dann anzulegen, wenn Flächen (Polygone) andere Flächen mit abweichenden Flächeneigenschaften enthalten. Dies entspricht den Regeln der simple features für Polygone.

  2. Die Praxis in OSM zeigt, dass entgegen den Vorschlägen der wiki
    http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon
    sowie dem simple-features-Standard bestimmte Objekte mit Flächenattributen (building=yes, amenity=parking u.a.) in der Regel nicht als inner eines Multipolygons angelegt werden, obwohl sie in einem anderen Polygon (z.B. landuse=residential) liegen. Dies wird von den Mappern akzeptiert und von den üblichen Renderern auch dargestellt.

  3. Das Erfassungs-Schema für Flächen in OSM ist für eine detaillierte Erfassung sich überlagernder Flächeneigenschaften unzureichend, fehleranfällig und deshalb entwicklungsbedürftig. Hierbei sind die Fähigkeiten des durchschnittlichen Mappers und die Möglichkeiten etablierter Renderer zu berücksichtigen.

  4. Die Einführung und strikte Beachtung der simple features - selbst ohne die abstrakte Klasse - http://www.slidefinder.net/g/geoinformation_iii_vorlesung/5859813
    Folie 11
    würde eine komplette Restrukturierung des Datenbestandes und –modells sowie komplexe Fehlerbereinigungen mindestens für Flächenobjekte zur Folge haben und den durchschnittlichen Mapper sicher überfordern.

Ohne auf einzelne Beiträge gezielt einzugehen:

Die mir bekannte Masse von Auswertungen der OSM-Daten setzt die Informationen optisch um. Die von mir vorgeschlagene Bereinigung des landuse-Schlüssels müsste doch über style-files möglich sein. Oder spricht neben den bisherigen Ausführungen etwas grundsätzlich dagegen?

Die grundsätzliche Frage ist doch, welche Vor- oder Nachteile mein Vorschlag unter Berücksichtigung aller Interessen und Zwänge (Erfasser, Datenbank; Auswertung) hat und ob die Vorteile oder die Nachteile überwiegen. Wenn da ein Trend erkennbar ist und Kompromisse möglich sind, bin ich gerne bereit, die Idee fallen zu lassen oder den steinigen Weg des proposals zu beschreiten.

Wenn ich ab Zoomfaktor 10 hier schaue
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=9.54763&lat=50.53758&zoom=10&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
und über die Karte wandere, stelle ich fest, dass die meisten MP-Fehler und –Warnungen mit großflächigen landuse-Objekten (überwiegend forest) zusammenhängen. Da sind aber Kleinflächen, die überlagern, jedoch nicht in MP’s eingebunden wurden noch nicht einmal dabei.

Mit meinem Vorschlag will ich diese Not ein wenig mildern. Wir haben nur zwei Möglichkeiten:
Entweder wir wenden stringente Regeln an und vergraulen Mapper, indem wir ihnen den Spaß verderben, oder wir leben mit akzeptablen Kompromissen, deren Ungenauigkeiten maschinell zu bewältigen bzw. bereinigen sind.

42

Bei Punkt 3 sehe ich kein Problem. Die Polygone überlagern sich dann genauso, wie sich die Flächeneigenschaften überlagern. So wie ich deinen Vorschlag verstanden hab, ändert er aber auch nichts an der Problematik.

Bei OSM gilt die Eigenschaft, die ein geschlossener Weg hat immer für die gesamte eingeschlossene Fläche. Als Mapper muss ich schauen, ob das in dem gewünschten Detaillierungsgrad so ist, dann reicht ein geschlossener Weg oder ob es eben nicht so ist und es innerhalb der Fläche einen Bereich gibt, der nicht diese Eigenschaft hat, dann scheide ich diesen Bereich aus.

Zu dem überwiegend ist mir noch ein Bsp eingefallen, was meiner Meinung nach mit deinem Beispiel logisch nicht funktioniert.

Man hat eine rechteckige 8. In den beiden eingeschlossenen Flächen ist Wald, an dem Rand ist ein dünner Streifen Wiese. Nach deinem Vorschlag würde ich jetzt ein umschließendes Polygon zeichnen müssen, dem ich sage, hier ist mehrheitlich Wald (Wald ist flächenmäßig mehr vorhanden als Wiese) und innen zeichne ich dann 2 Polygone die nur Wald sind. Die Info, dass außenrum Wiese ist nicht erfasst. Es sei denn, ich würde die Hülle mit überwiegend Wiese eintragen, was aber logisch falsch ist und daher dem Mapper schwer zu vermitteln sein wird.

43

Das ist genau so ein Fall, der Probleme wegen der Überwiegend-Definition für landuse bereitet und weshalb ich einen neuen Tag für ausschließliche (exklusive) Nutzungen wünsche. Ich gebe dem Schlüssel für diese exklusive Nutzung jetzt mal den Arbeitstitel “area_usage”.
Wald hätte dann für ausschließliche Flächeneigenschaft area_usage=forest. Forest impliziert vom Begriff für mich eine ausschließliche Nutzung. Unter landuse müsste es daher sinnvollerweise landuse=forestry analog zu farmland heißen. (Ich will hier jetzt aber nicht über Begriffe streiten. Wichtig ist die Eindeutigkeit, wonach man für farmland z.B. agriculture nehmen könnte, um den übergeordneten Charakter eines größeren Bereiches zu betonen.)

Deine Schlussfolgerungen sind bei strenger Auslegung des Überwiegend-Prinzips richtig. Mit dem neuen Schlüssel geht das leider dann auch nur über ein MP, denn sowohl Wiese als auch Wald würden dann zum Schlüssel area_usage (exklusive Eigenschaft) gehören.

P.S.: An den englischen Begriffen müssen wir sicher noch arbeiten, damit muttersprachlich korrekte, aber auch für Fremdsprachler eindeutig verständliche Schüssel und Werte entstehen. Das ist aber ein generelles OSM-Problem. Ich denke da z.B. nur an “node”, das Knoten heißt aber in OSM allgemeiner für Punkte verwendet wird, die allerdings auch Knoten sein können :roll_eyes:

44

Was der Begriff forest (für dich) impliziert ist aber unerheblich. Wofür es steht, ist im wiki definiert und so sollte man ihn als Mapper auch einsetzen. :wink:

Was heißt bei strenger Auslegung? Entweder es gibt so ein Prinzip (was ich als sehr sinnvoll erachte) oder es gibt keines. Solche Fälle werden sehr viele Fehler erzeugen. Der Mapper “braucht” ein Schema F, das er immer anwenden kann. Bspw. bei verschachtelten Flächen das MP. Mit deinem Vorschlag trägt der Mapper die Flächen erstmal alle ein und muss dann schauen, ob alle das Gesamtkonstrukt betreffenden Tags noch stimmen, oder ob sich das “überwiegend” der Hülle geändert hat, dieses anpassen und evtl. dann noch ein MP anlegen.

Wäre es nicht sinnvoller, ein technisch gut funktionierendes Konstrukt nicht durch etwas schlechteres zu ersetzen, sondern die Editoren dahingehend zu vereinfachen, dass es leichter ist mit dem Konstrukt zu arbeiten.

Ob es für ein aufgeräumtes Landuse-Schema eine Mehrheit geben wird ist sehr fraglich. Aber ich will dich nicht davon abhalten.

PS: Meiner Meinung war es eher ungeschickt, deine beiden Vorschläge zu verknüpfen, weil sie nicht wirklich etwas mit einander zutun haben.

45

Wenn wir Schema F beziehungsweise Prinzipien wollen, müssen wir die aber konsequenterweise z.B. auch für building=yes in landuse=residential anwenden, denn diese Hauswer sind datenbanktechnisch auch Polygone (Flächen) wie landuse=forest. Das machen wir bisher aber nicht.

Wir müssen uns entscheiden.

Wenn du für die konsequent klare Linie bist, bitte ich jedoch um einen Vorschlag wie du bei building=yes in einem MP mit outer landuse=residencial das Problem fehleerresistent und anwenderfreundlich löst, wenn z.B. Reihenhäuser mit gemeinsamen Linien bzw “Trennwänden” über gemeinsame nodes dazwischen streng nach simple features und auch nach wiki wegen touching inner eigentlich unmöglich sind.

46

Moin,
sorry wollte mich eigentlich raushalten. :wink:

Das Problem ist, dass wir eine semantische Ebene haben und eine geometrische.
Beim “building im residential” gehört das building mal zum residential oder nicht, je nachdem
ob man die semantische oder die geometrische Ebene betrachtet.

Chris

47

Der Ansatz bei OSM ist ja auch anders.

Um beim Gebäude im Wohngebiet zu bleiben:

Trifft die Eigenschaft Wohngebiet auch auf den Inhalt vom Gebäude zu.

  • JA → einfach Polygon malen
  • NEIN → Multipolygon erstellen.

Bei residential kann man recht häufig mit JA antworten. Wenn man in den Wäldern bspw. die Ameisenhaufen als Polygon erfassen würde, könnte man auch mit JA antworten.

48

Semantisch durch die Bedeutung, geometrisch durch die mathematische Struktur?
Hilft mir und anderen als Laie das hier weiter?
http://www.ikg.uni-hannover.de/fileadmin/ikg/staff/publications/sonstige_Beitraege/SesterKielerGoesseln_koenigslutter2007.pdf

Bitte, wenn du helfen kannst, diesen gordischen Knoten hier zu lösen, dann tu es, auch wenn es für mich bitter endet.

49

Und um das auf die Wiese im farmland zu übertragen:
Wiese ist landwirtschaftliche Nutzung und somit nur Polygon malen. Ebenso farmjard…

Die Lichtung im Wald als grasbewachsene Fläche und mit landwirtschaftlicher Nutzung als Wiese wäre keine Forstwirtschaft und somit inner eines MP. Wenn Sie aber Folge eines Kahlschlages ist und das Gras einfach so wuchs, und vielleicht wieder aufgeforstet wird (weiß man’s?), wäre sie einfach nur ein Polygon… :roll_eyes:

50

Im Prinzip ja. Wenn du in die Datenbank ueberlagernde Flaechen eintraegts, dann sollte dir als Mapper erst mal klar sein, was du damit eigentlich genau meinst. Und da happert es z.Z. meist schon.

Ueberlagern sich die Eigenschaften in der Schnittflaeche => einfache Polygone.
Gilt innerhalb der Schnittflaeche nur noch die Eigenschaft des inneren Polygons => Multipolygon-Relation.

Diesen logischen Zusammenhang bekommt man weder durch irgend welche neuen Tagging-Schemata noch durch irgendwelche Layer-Konstrukte sauber aufgeloest.

Gruss
Torsten

51

Verstehe ich dich als mir bekannter Mapper der “Einfach und Robust”-Fraktion richtig?
Wir werden kein Schema der reinen Lehre zustande bringen und Kompromisse eingehen müssen. Ziel unserer Bemühungen im Zusammenhang mit einer sinnvollen Erfassung muss es sein, es dem Mapper nicht zu schwer zu machen, wobei wir allerdings die Datenqualität und Auswertungsmöglichkeiten im Auge behalten müssen.

Wenn dem so ist, habe ich noch Hoffnung auf Bewegung zum Thema.

52

Ich hoffe, so langsam faellt bei dir der Groschen :wink:

Nehmen wir mal ein anderes Beispiel: Wir haben einen Park (leisure=park) und in der Mitte ist ein Gebaeude (building=yes).

Fall 1: Das Gebaude ist ein Bueroturm. Hier ist es ja wohl zweifellos klar, dass das Gebaeude nicht Teil des Parks ist. Also benutzt man eine multipolygon-Relation, um ein Loch in den Park zu schneiden, und dieses Loch ist das Gebaeude in der Mitte.

Fall 2: Das Gebauede ist ein Gewaechshaus, in dem die empfindlicheren Pflanzen des Parks ausgestellt sind. Dieses Gebaeude gehoert also mit zum Park und kann als einfaches Polygon “ueber” den Park gelegt werden, ohne dass man dazu eine weitere Relation benutzt.

Wozu braucht man solche Unterscheidungen?
Zum einen braucht man das fuer eine saubere Kartendarstellung. In Fall 1 waere es schlicht weg falsch, wenn auf der Karte der Park das Gebaeude ueberdecken wuerde. In Fall 2 waere das durchaus eine korrekte Darstellung, wenn auf der Karte nur eine der beiden Eigenschaften an einer Stelle angezeigt werden kann, dann muss sich der Kartenersteller halt fuer eins entscheiden. Und diese Entscheidung kann je nach Zweck der Karte unterschiedlich ausfallen.
Zum anderen braucht man einen Loch-Mechanismus, da es nun mal Flaechen mit Loechern drin gibt. Im Loch selber muss ja nicht unbedingt was sein. Ok, in der praxis ist da immer irgendetwas, aber das kann ja was sein, was der Mapper nicht erfasst oder was der Renderer nicht darstellt. So braucht man dann aber doch immer noch das Loch.

Natuerlich gaebe es auch andere Methoden, um solche Probleme zu loesen. Die Multipolygone sind auch nicht mein bevorzugter Ansatz, da sie leichter zu Zeichnen aber schwerer auszuwerten sind als manch andere Moeglichkeit. Aber OSM wird nun mal durch die Mapper getrieben.

Das deine Idee mit einer Unterscheidung anhand von tag-Listen nicht funktionieren kann, ist dir hoffentlich anhand des Beispiels klargeworden (die Tags sind ja identisch, aber die Bedeutung ist eine andere). und selbst wenn man das hinbekommen koennte (man koennte ja die Tags beliebig kompliziert machen), so wuerde das ganze nur funktionieren, wenn jeder Mapper sich ganz genau nach dem Schema richtet. Hier bei OSM? Vergiss es!

Das einfach und robust ist an sich kein Widerspruch zu multipolygon-Relationen: Wenn die Wirklichkeit extrem kompliziert ist, dann braucht auch die Erfassung in der Datenbank eine gewisse Komplexitaet, um die Wirklichkeit passen abzubilden.
Oder um es etwas mathematischer auszudruecken: Wenn man eine bestimmte Menge an Information hat, dann gibt es eine untere Schranke, wieviel Bits man mindestens braucht, um diese Information verlustfrei zu codieren. Da kann man sich drehen und wenden wie man will, es ist einfach nicht moeglich, unter diese Grenze zu kommen.

Wenn man nicht ohne komplexe Konstrukte auskommt, so sollte man dann immerhin bemueht sein, sie so selten wie moeglich einzusetzen. So entseht z.B. Komplexitaet haeufig ueber zu grosse Objekte. Wenn ich einen landuse=farm ueber 30^2km eintrage, dann mus sich da natuerlich viel Loecher reinschneiden. Wenn ich aber jeden acker einzeln erfasse, dann komme ich da auch ohne Loecher aus.

Gruss
Torsten

53

@de_muur:
Der Groschen ist gefallen, allerdings kam er wegen der bisherige Diskussion unten wieder raus. Deshalb versuche ich es mal mit nem anderen :wink:
Auch deinen Ausführungen entnehme ich, dass alles von der subjektiven Wahrnehmung des Mappers und dessen Umsetzung seiner Wahrnehmung in Form von Datenbankeinträgen ist, wobei sich der Mapper an Vorschlägen orientiert, die oft semantisch bedingt einen zu großen Interpretationsspielraum haben oder mehrere Möglichkeiten zulassen.

Darf ich noch einmal auf den Ausgangspunkt für meine Überlegungen verweisen:
http://forum.openstreetmap.org/viewtopic.php?pid=162988#p162988

Primär geht es mir um landuse-Schlüssel, die Gebietscharakter haben und noch nichts über den physischen Zustand der Erdoberfläche, deren Bewuchs oder die Bebauung aussagen.
Dies sind für mich insbesondere:
industrial=Gewerbegebiet
residential=Wohngebiet
forest=(im Sinne von) Forstwirtschaft (somit eher forestry)
farmland=(im Sinne von) Landwirtschaft (somit eher agriculture)
military=Militärgebiet

Ich meine, dass diese Werte über einen eigenen Schlüssel eine Bedeutung ähnlich boundary haben sollten, da sie nicht gegenständlich sind. Renderer könnten Sie dann z.B. transparent interpretieren. military wird ja schon in mapnik so erkannt und dargestellt.

Sollte jedoch die Landwirtschaft eine Insel in der Forstwirtschaft sein, bleibt uns nur das MP. Aber so hätten Kartenentwickler und -anbieter wie z.B. nop leicht die Möglichkeit, auf die Darstellung der zahlreichen kleinen Wiesen und Äcker zu verzichten, aber das Gebiet der überwiegenden Nutzung abzubilden.

Bei dieser Vorgehensweise, hätten wir es auch nicht nötig als area angelegte highways aus residential ausschneiden zu wollen.
Bei der (deiner)bisherigen Betrachtungsweise gibt es da analog zu deinem Park-Gebäude-Beispiel aber auch Interpretationsunschärfen, wenn man darüber nachdenkt, ob z.B eine vierspurige primary noch residential ist oder ob das nur für eine zweispurige primary zutrifft :roll_eyes:

54

100% agree with hurdygurdyman.

Oder anders ausgedrückt, wenn ich einen Wald auf einer A1 Bayerkarte sehe, dann interessiert mich nicht das irgendwo Lichtungen sind. Da wir mehr und mehr Richtung Vektorkarten gehen, ist die Karte nicht renderbar, wenn überall Löcher sind. Daher ist der Vorschlag alle Gebiete ohne Überlappung zu zeichnen, nochmal schlimmer wie der Status quo, weil dann gar nichts mehr funktioniert. Kartenrendering kann immer (und das wird sich auch nie ändern) für verschiedene Zoomstufen nur über eine Selektion von Werten laufen, die man rausschmeißt. (etwa Niemand wird für eine A4 Deutschlandkarte higwhay=residential rendern).

Dir wirkliche Lösung wäre, dass OSM wie auch alle anderen Kartendatenbanken, ein echtes Layersystem bekommt (das kann ruhig in dieselbe Datenbank rein, wobei separate Datenbanken auch einen Charme hätten - insbesondere für Editoren) womit die Probleme von was ist oben/was ist unten vorbei wären. Für Layer=0 (also die höchste Auflösung) könnte man ruhig vom Verstand, hier gibt es keine Überlappungen ausgehen. Für andere Layer wäre das aber katastrophal. Weil ein großer Wald eben für Layer=Deutschlandansicht - eben nicht aus 100.000 Teilen bestehen darf (unmöglich für eine Vektorkarte zu rendern - bzw ist sogar das zusammenfassen der 100.000 Teile in einen Teil nicht korrekt machbar)

55

Zuerst einmal vielen Dank für deine Zustimmung, wobei mir die Sichtweise aus der Renderer-Perspektive sehr wichtig ist.
Mit einem echten Layersystem sollten wir aber vorsichtig sein, wenn die Entscheidung, welcher Layer verwendet wird, beim Mapper liegt.
Beispiel:
Ich kenne Ecken, da wurden Bäche durchgehend mit layer=-1 getaggt. Ich vermute mal, damit z.B. keepright nicht an Kreuzungen mit Tracks usw. meckert oder weil es sonst erforderlich wäre, an diesen Kreuzungspunkten mühsam entweder den Bach als tunnel oder den Weg als bridge zu taggen. (Nein, ich unterstelle keinem Faulheit, sondern vermute Effektivität als Grund).
Das ist aber total falsch, da layer=-1 “unter der Oberfläche” bedeutet, welche aber über weite Strecken durch die Wasseroberfläche gebildet wird und somit layer=0 bzw. keine layer-Angabe korrekt ist.

Gerade bei großen Flächenobjekten (z.B. forest) sieht der Mapper aber beim Bearbeiten einer kleinen Fläche nicht, auf welchem Layer diese Großfläche liegt, um daraus das richtige Darunter oder Darüber für seine bearbeitete/angelegte Fläche zuverlässig ableiten zu können.

Deshalb bevorzuge ich einen Ansatz, der es dem Renderer/Editor über eindeutige Schlüssel ermöglicht, dieses drunter und drüber und was er davon in welcher Zoomstufe darstellen soll, selbst zu entscheiden. Berichtige/belehre mich, wenn das über Styles oder andere Routinen nicht gehen sollte.

56

Das Layersystem sollte nicht statisch, sondern dynamisch sein. Dann würde es schon funktionieren. Evtl halt drei wirklich separate Layer (einer für Großkarten, einer für klassische Karten bis 1:25.000 von den Details her, einer für Detailsachen wie area:highway, lanes (evtl sollten die komplett separat sein) und etwa Häuser detailliert.). In jedem Layer würde man trotzdem Objekte mehrfach eintragen mit unterschiedlichen details, und dies halt über einen Key abgrenzen. Als Renderer könnte man dann je nach priorität Sachen ab/aufwerten. Es ist ja schon komisch, dass die Kindergartenübung eine Weltkarte mit Kontinenten, großen Gebirgszügen, Ländern, evtl noch Haupstädten als Punkte zu erstellen, aus OSM eigentlich unmöglich ist, aber man die notwendigen Daten bestimmt aus 10 PD Quellen holen könnte.

Und Achtung, ich meine mit Layer nicht oben oder unten, sondern unterschiedliche Detailebenen.

57

Kapiert…
Entspricht nicht dem OSM-Verständnis von layer, deswegen gut, das du darauf hinweist, bevor hier alle aneinander vorbei reden :sunglasses:

58

Hier ein abschreckendes Beispiel:
http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=9.06069&lat=48.54327&zoom=16&opacity=0.80&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
Parkplätze sind sowohl mit als auch ohne Multipolygon inner getaggt, das gleich gilt für landuse=forest
Bezüglich des Rendern mit Mappnik sehe ich keinen Unterschied.
Mein Vorschlag hier: aller inner weg, es geht auch gut ohne.
Generell erscheint mir der Ansatz, das Innere über das Äußere zu zeichnen, auch hier zutreffend.

59

Leute hoert doch endlich mal auf, bei den Flaechen nur an die Darstellung im Renderer zu denken.

Entscheidend fuer den Eintrag in die Datenbank ist doch alleine, welche Eigenschaften dort gelten. Was der Renderer davon anzeigt, ist allein seine Sache.

Ziel muss es doch sein, dass ich mir einer Koordinate die Datenbank abfragen kann, was an dieser Koordiante vorliegt. Und dann will ich alle Eigenschaften fuer diese Koordinate haben und nicht nur das, was in diesem Falle am schoensten im Renderer aussieht. Und ich will auch bestimmt keine Eigenschaft als Ergebnis geliefert bekommen, die an dieser Position nicht gilt aber drumherum, nur weil sie in der Rendereransicht von irgendetwas anderem ueberdeckt wird.

Gruss
Torsten

60

Seh ich auch so. Ein Haus auf der Wiese ist eben ein Haus auf der Wiese. 10 Häuser sind eben eine Siedlung auf der Wiese. Nur wie viele Häuser braucht man damit die Wiese keine mehr ist?