Empfehlenswerter Detailgrad von Landuse?

buedner · 2012-05-21T17:20:15.000Z

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

MoTaBi · 2012-05-21T17:59:09.000Z

buedner:

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.

+1!

moenk · 2012-05-22T08:23:33.000Z

buedner:

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

Moin alle,

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

SCNR.

LG,

-moenk

fireball2 · 2012-05-22T08:23:39.000Z

+1!

Taunide · 2012-05-22T09:20:34.000Z

buedner:

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 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)

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.

So ist es.

MoTaBi:

buedner:

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.

+1!

+2! oder drei??

mtb · 2012-05-22T12:17:20.000Z

buedner:

…
Als extremes Ärgernis empfinde ich die Verbindung von Flächen und Wegen. Es erschwert, unabhängig vom verwendeten Editor, das Editieren heftig. …

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

wambacher · 2012-05-22T12:38:14.000Z

mtb:

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

aighes · 2012-05-22T14:14:31.000Z

+1

OliverG · 2012-05-22T19:13:13.000Z

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)

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.

buedner · 2012-05-22T20:00:46.000Z

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

Netzwolf · 2012-05-22T23:22:01.000Z

Nahmd,

OliverG:

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.

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

fireball2 · 2012-05-23T08:15:05.000Z

Netzwolf:

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.

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 :/.

Tordanik · 2012-05-23T20:32:18.000Z

Netzwolf:

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.

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.

Zecke · 2012-05-23T22:17:25.000Z

Tordanik:

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?

Radeln · 2012-05-24T07:31:46.000Z

fireball2:

Netzwolf:

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.

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 :/.

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

Noframe · 2012-05-24T08:03:09.000Z

Radeln:

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

Kein Wunder:

Zurzeit sind 19,792 Artikel und 84,145 Seiten (also auch kurze Artikel) im Wiki vorhanden!

Wer soll da noch durchschauen…

chris66 · 2012-05-24T08:07:08.000Z

Moin,
Meckern ist schön und gut, dadurch ändert sich aber nichts.

Jeder darf JOSM Patches schreiben, das Wiki verbessern, Vorschäge für die 0.7 API einreichen etc.

Wolfgang_B · 2012-05-24T08:38:32.000Z

Zum Landuse: Es wäre ohnehin besser, Landuse in einer eigenen Ebene zu erfassen. Aber eine Umstellung ist wohl nicht mehr möglich.

de_muur · 2012-05-24T08:49:13.000Z

Zecke:

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.

Bei JOSM erreicht man das ja durch Gedrueckthalten der Alt-Taste beim Rechts-Klicken. Ich habe allerdings nie verstanden, warum das nicht einfache der Default-Modus für das ganz normale Anklicken sein kann.

Gruss
Torsten

Zecke · 2012-05-24T08:54:10.000Z

chris66:

Meckern ist schön und gut, dadurch ändert sich aber nichts.

Das kommt darauf an.
Wenn ich nur sage: “Das und das ist schlecht”, hilft das ein wenig: Die Entwickler können zumindest ein Augenmerk darauf werfen.
Wenn ich sage: “Das und das ist schlecht, so und so könnte man es besser machen”, dann ist das ein konstruktiver Verbesserungsvorschlag. Wenn die Bereitschaft da ist, auf Userfeedback einzugehen, sollte das also durchaus helfen.

Nicht jeder ist in der Lage, z.B. Programmcode zu verstehen oder gar zu verbessern. Dennoch ist Feedback hilfreich. Usability ist ein wichtiges Thema in der Softwareentwicklung und die Tips dazu können oftmals von nicht IT-lern besser formuliert werden als von Entwicklern, die oftmals a) eine zu technische Sicht haben und b) zu sehr in ihren persönlichen Code verliebt sind.

Gruß,
Zecke