Empfehlenswerter Detailgrad von Landuse?

Ohne jetzt alles gelesen zu haben, kurz meine Meinung:

  • Daten in der Datenbank ist wichtiger als Rendering, wo man locker generalisieren kann → man kann nicht genau genug erfassen, sowohl geometrisch als auch inhaltlich!

  • Die Welt sollte flächendeckend und möglichst topologisch sauber einen (vorherrschenden) landuse haben - Lücken gibt es auf der Welt nicht

  • für Zwischenformen, bspw. Sukzessionsflächen kommt man ohne Generalisierung sowieso nicht aus

Der Nutzung der Daten sind keine Grenzen gesetzt, ich denke da nur an Versiegelungsgeschichten und Hochwassermodelle, aber auch meteorologische Geschichten, die man mit hochgenauen Daten super modellieren kann. Aber auch die Vielfalt und der Schutz einer Landschaft kann man mit guter Dokumentation fördern.

Die Welt grob zu erfassen, das macht man nur, wenn man stark begrenzte Ressourcen hat und/oder sich die Daten zu schnell ändern.

So ist zumindest meine Sicht auf die Landuse-Problematik.

Grüße
Westwind

Jau leider gibt es keine einheitliche Meinung ob es gut ist Wege und angrenzende Flächen mit einander zu verschmelzen oder getrennt zu handhaben. Da fehlen uns bislang auch die Anwendungen, die von so einer Unterscheidung profitieren würden (z.B. Routinganweisungen a la “links wo die Koppel endet”). Ich persönlich habe beides ausprobiert und mich letzten Endes für das verschmelzen entschieden, da es mir topologisch sauberer erscheint (modellierung eines “grenzt an Straße an”, …) und im Editor übersichtlicher ist. Das ist aber nur meine eigene Meinung, die Argumente derjenigen, die das lieber auseinander halten, haben auch etwas für sich.

Er hat Jehova gesagt!

:smiley:

:wink:

Wenn es (angeblich oder wirklich) keine gibt, hat das mit einer gewissen Beliebigkeit zu tun, die aber nicht zweckförderlich ist.

Der Name OpenStreetMap deutet darauf hin dass es primär um Straßen und Wege geht, und dass es sich um eine Karte handeln sollte. Für die Orientierung auf Straßen und Wegen (für Autofahrer, Radfahrer und Fußgänger, als die wichtigsten Benutzerkategorien) sind primär drei “landuse” Kategorien erforderlich, von denen man die ersten beiden mappen sollte. Die dritte ergibt sich aus der Differenz:
a - Wald
b - Siedlung oder sonstige Bebauung, Häuser
c - alles was nicht a oder b ist, z.B. Feld, Wiese, Gärten…

Diese “Landschaften” zeigen auch die einfachsten, sehr schematischen Navis.

Alles was darüber hinausgeht ist “nice to have”, zweitranging, und sollte auch nachranging gemappt werden.

Vielen Mappern scheint das auch so bewusst zu sein. Auch einigen (aber nicht allen) OSM Forenten.

Hmm das stimmt schon mit den Prioritäten Taunide (Im OSM Buch gibt es da auch eine empfohlene Liste). Nichts desto trotz sind wir ja ein VGI Projekt, also kann doch jeder das machen, was ihm Spass macht. Zu experimentieren halte ich da durchaus für angebracht, damit später man (vielleicht) von den Erfahrungen ebend dieser profitieren kann. Dass es bei OSM nicht den einen goldenen Weg gibt ist zwar verwirrend, aber bis jetzt habe ich noch keine deutlich negativen Auswirkungen festgestellt.

Ich glaube aber langsam wurde das Thema ausreichend behandelt (siehe Zwischenzusammenfassung weiter vorne) :wink:

Das sind in etwa die Erkenntnisse, zu denen ich nach anfänglichen Experimenten mit flächendeckendem Mapping auch gekommen bin.
Ich habe dann noch (für mich) Acker zur Standardlandnutzung erklärt und verzichte seitdem völlig darauf, Äcker zu mappen, ohne dass mir als OSM-Nutzer etwas fehlen würde.

Das Bemühen, Landnutzung komplett zu erfassen, erhöht die Datenmenge und die Komplexität des Datenbestandes gewaltig, es steht dem aber keine in gleichem Maße erhöhte Informationsdichte gegenüber.

Als extremes Ärgernis empfinde ich die Verbindung von Flächen und Wegen. Es erschwert, unabhängig vom verwendeten Editor, das Editieren heftig. Auch wenn es technisch irgendwie beherrschbar ist, möchte ich mich, wenn ich nur einige wenige Änderungen an Wegen vornehmen will, nicht mit gewaltigen angrenzenden Polygonen beschäftigen müssen.

Ich weiß auch von Anderen, dass sie schon auf Ergänzungen im Wegenetz verzichtet haben, weil sie keine Lust hatten, sich mit Flächennutzungspolygonen auseinanderzusetzen.

Für einen Anfänger muss ein flächendeckend gemapptes Gebiet, das erste mal in den Editor geladen, eine ziemlich irre Erfahrung sein. Möglicherweise auch die letzte, die er mit OSM macht.

Als Lösung könnte ich mir eine Art Layermodell vorstellen, mit dessen Hilfe flächenhafte und lineare Daten getrennt werden.

Gruß buedner

+1!

Moin alle,

ich könnte mir überhaupt mal vorstellen dass Linien und Polygone unterschieden werden :wink:

SCNR.

LG,

-moenk

+1!

Das ist nicht bloß Deine Privatansicht. Das wird auch schon seit mehr wie 100 Jahren von den Machern militärisch-/topografischer u. Straßenkarten so gesehen, deswegen sind auf diesen Karten Ackerflächen **weiß **(d.h. unbedrucktes Papier)

So ist es.

+2! oder drei?? :slight_smile:

So ist es!!! Mein Vorschlag: JOSM, P2 etc. sollten das bei neuen Objekten gar nicht mehr zulassen - oder zumindest eine deutliche Warnung ausgeben.

Einen winzigen Schritt hat Josm vor einiger Zeit in diese Richtung gemacht: Er motzt, wenn ein Way an einem Landuse endet.
Lieber wäre mir, dass er immer motzt, wenn ein Way mit einem Landuse verbunden ist (also auch Kreuzung mit gemeinsamen Node oder auch gemeinsame Strecke)

Gruss
walter

+1

Wärs nicht besser, wenn die Editoren verbessert würden, statt die Daten in einem “einfacher zu bearbeitenden Format” einzutragen?

Beispiel http://www.openstreetmap.org/?lat=53.662767&lon=12.259119&zoom=18&layers=M : das Kleingartengebiet wird im Süden von einer Straße abgeschlossen. Soll ich jetzt die Breite der Straße ausmessen und dann die Punkte der allotments-Fläche um die Hälfte der Straßenbreite von der Straße weg versetzen? Find ich nicht richtig - die Kleingartenparzellen beginnen nun mal genau an der Straße.

Mir geht es nicht um “richtig” oder “falsch”, sondern in erster Linie um die praktische Möglichkeit, vorhandenen Datenbestand einfach und problemlos zu editieren.

Und eine Lösung für dieses Problem ist nun mal die Trennung von Linien und Flächen indem man die Fläche am Straßenrand enden lässt.

Gruß
buedner

Nahmd,

Ich benutze auch da, wo eine Fläche an einer Straße endet, die Straße als Grenzline.

Das kommt aber nicht wirklich häufig vor. Wenn z.B. ein Wald an einer Straße endet, ist meistens noch soviel Grünland zwischen dem Saum und der Straße, dass man die Waldgrenze in einem Abstand von der Straße ziehen kann.

Albern finde ich, die Flächengrenzen in einem willkürlichen Abstand von der Straße zu malen, nur um die nicht zusammenlegen zu müssen. Das gibt ähnliche Effekte wie die in einem willkürlichen Abstand zum Weg gesetzten Bänke, die dann mal eben 50m vom Weg in der Botanik stehen, oder Bushaltestellen “ein Stück” neben der Straße – auf dem Friedhof.

Das Limit des “Weg als Grenze” siehst Du aber dann, wenn Du Dein Gartengrundstück mit einem Zaun umgeben willst: dann nämlich muss die Grundstücksgrenze von der Straße abgesetzt sein. Ob Du die Straße als Grenze benutzt oder eine eigene Grenze ziehst, hängt unter anderem vom Grad des Micromappings ab, das Du vorhast.

Wenn ich gute Laune habe, zeichne ich ein kleinen dörflichen Siedlungen auch schon einmal die zahlreichen Hecken ein, die die Grundstücke von der Straße trennen. Ich erfasse da aber nicht die Einzelgrundstücke, sondern belasse das als rein großes Residential.

Ich glaube, ein großer Teil der Diskussionen entsteht schlicht daraus, dass manche Leute eine panische Angst vor den Relationen haben. Dabei sind die – insbesondere wenn man weiß, wie die Profis arbeiten – das Natürlichste der (Geodaten-)Welt.

Ich sehe mittlerweile nicht mehr Areas und Relationen/Multipolygone, sondern Features und Geometrien. Wenn ein Flächenfeature zusammenhängend ist und die Grenzen mit niemandem teilt, wird das Feature mit einer Way/Area-Geometrie dargestellt. Ist es komplexer, wird es zum Multipolygon. Nicht mehr. Nicht weniger. Keine Weltanschauung.

Bei OSM krankt vieles an dem zu einfachen Datenmodell und dem zu geringen Abstraktionsgrad beim Zugriff auf die Daten: dass jeder einzelne immer wieder das Bestimmen des Mittel/Schwerpunktes eines Flächenfeatures neu entwickeln muss, und vor allem dass die Datennutzer unterschiedliche Regelsätze für das gleiche (Flächen)-Feature je nach der verwendeten Geometrie erstellen müssen, erzeugt eine unsinnige Komplexität und überflüssige Doppelarbeit.

Ähnliches gilt auch für den Unterschied zwischen der Punkt- und der Flächendarstellung von Features: da auch hier getrennte Regelsätze benutzt werden, kann passieren, dass der Name eines Features dargestellt wird, solange ich eine Punkt-Geometrie benutze, aber verschwindet, wenn ich Way/Area-Geometrie benutze, weil im zweiten Fall z.B. der Text nur dargestellt wird, wenn er in die Fläche passt. Das ist absurd.

Und weil das Datenmodell nichts von komplexeren Strukturen (wie z.B. Multiplygon-Geometrien) weiss, kann es keine Integrität durchsetzen und sicherstellen. Bei MPen wird als gegeben angenommen, dass da immer wieder Schrott gespeichert ist. Was gäbe es für ein Geschrei, wenn immer wieder einmal Ways Nodes ohne Koordinaten enthielten oder Nodes, die es überhaupt nicht gibt?

So viel man aus den OSM-Daten auch machen (frickeln) kann: wir sind bezüglich Datenmodell und Qualitätssicherung immer noch auf der “Malen nach Zahlen”-Ebene.

+1 -1 *1 /1 ×1 ÷1 ← zur Selbstbedienung

Gruß Wolf

Insgesamt muss ich Dir da schon recht geben, wenn OSM sich weiterentwickeln will, dann müssen wohl zunehmend Relationen eingesetzt werden um der Datenflut Herr zu werden. Allerdings “arbeiten” für OSM kaum Profis sondern überwiegend Hobby-Mapper. OSM wird für Neueinsteiger zunehmend komplizierter. Das könnte auch der Anfang vom Ende sein, wenn die Hürde des Neueinstiegs zu schwierig wird und daher viele frustriert beim Einstieg aufgeben. Daher müßte man sich darauf konzentrieren möglichst einfache Bearbeitungswerkzeuge “intuitiv für jedermann” zu schaffen, aber ich sehe die nicht wirklich kommen.
Übrigens “panische Angst vor Relationen” kann man auch als “zu kompliziert” umschreiben, daher lassen es auch die meisen. Andere wiederum arbeiten angstfrei darauf los, was auch nicht immer gut sein muss :/.

Na ja, wenn die Zielgruppe panische Angst vor einem Feature des Datenmodells hat, dann ist entweder das Datenmodell, der Editor oder beides falsch designed. Dem Enduser kann man das kaum vorwerfen. Aber das hast du ja mit deiner Kritik am Datenmodell vermutlich auch so gemeint.

Um auch noch meinen Senf zum Flächenproblem abzugeben: Ich kann die gemeinsamen Knoten von Flächenpolygonen und Straßen nicht gut leiden (bei der Arbeit mit den real existierenden Editoren, nicht unbedingt aus theoretischen Erwägungen heraus). Es gibt hier Straßen, da kann man im JOSM schon kaum mehr zuverlässig die Straße auswählen, weil man stattdessen eine der beiden landuse-Flächen, die eine amenity-Fläche oder die 4 Buslinien erwischt, die da ebenfalls entlanglaufen.

Ein klassisches Beispiel mäßig designter Software: Wenn die Auswahl nicht eindeutig ist, sollte ein Fenster hochpoppen (nur als Beispiel, wie man es implementieren könnte, es dürfte einige andere geben), das fragt, ob man nun Straße X, Area Y, Multipolygon Z oder Relation a,b,c,d,e auswählen möchte. Stattdessen versucht die Software “schlau” zu sein und uns die Entscheidung abzunehmen. Warum muss ich gerade mit wachsendem Grummeln an MS Word denken? :roll_eyes:

Viel schlimmer finde ich das das zerfledderte und uneinheitliche Wiki. Für einen Neueinsteiger einfach chaotisch.