Automatisches Straßenbegleitgrün ....

OkerJoker · 2017-10-25T07:15:19.000Z

Harald Hartmann:

… dass es in Finnland der Straßenbegleitwald, in Schottland die Straßenbegleitwiese, in den Alpen der Straßenbegleitfels, in der Wüste der Straßengleitsand sein wird
…

Eine Schraffur oder Farbe für alles. Jeder weiß, was gemeint ist. Wie’s in die einzelnen Sprachen übersetzt wird, ist letztendlich egal.

ionr:

Meinst du etwa die Abstände zwischen den Straßenlinien und den Flächen? Sowas wie hier zum Beispiel?

Genau sowas meine ich.

ionr:

… Wird ja ohnehin von jedem Programm anders gemacht (OSM Standard, Cyclemap, Topomap, OSMAnd, Maps.me, Komoot wären gleich 6 populäre Karten, die alle völlig anders rendern) und die Darstellungen werden auch mal geändert. Gezeichnet wird wie es in der Realität ist und niemals für die Darstellung…

Maps.me macht alles grün. Da frage ich mich, warum ich’s bunt mache.

Jedenfalls fallen mir auf OSM Standard diese Lücken auf. Vielleicht könnte man ja die programmtechnische Darstellung so einrichten, das die automatisch gezeichneten straßenbegleitenen Flächen einen minimalen Abstand zur Linie der Straße haben.

ionr · 2017-10-25T07:19:56.000Z

Harald Hartmann:

ionr:

Die Straße verläuft über die Grünfläche und ist nicht mit dieser verbunden, dann zeichnet man die Straße einfach über die Fläche.

-1, also das ist erstens in der Realität schon nicht so, und wäre zweitens Tagging for the Renderer…

Für die Straßenfläche gibt es ja area:highway…

Gegen die -1 muss ich mich jetzt wehren. Das wird bei den meisten Straßen, die durch Waldstücke verlaufen, so gemacht.

geri-oc · 2017-10-25T07:32:49.000Z

In der Realität hat die “Straßenmeisterei” sich auch um das “Begleitgrün” zu kümmern. Das ist unterschiedlich breit und manchmal “Busch” oder Wiese mit Baumstreifen (Allee). Bei Autobahnen ist es meist noch mit Zaun versehen. Da die Straße nur ein “Linie” ist verläuft sie über die Fläche der “Straßenmeisterei”. Auch in einem “Wohngebiet” oder “Gewerbegebiet” verläuft die Straße als Bestandteil des Gebietes über diese.

Harald_Hartmann · 2017-10-25T07:43:35.000Z

Bei (kleineren) Forstwegen und Landwirtschaftswegen über Äcker hat man sich durchaus darauf geeinigt, dass diese ein Teil dessen sind, aber eine Verkehrsstrasse ist definitiv kein Teil des Strassen ** begleit** grüns

ADD: also in meiner Gegend (Thüringer Wald) ist überwiegend alles größer Track nicht durch die Waldfläche gezeichnet, sondern da endet die Waldfläche an der Straße

toc-rox · 2017-10-25T07:48:09.000Z

OkerJoker:

Jedenfalls fallen mir auf OSM Standard diese Lücken auf. Vielleicht könnte man ja die programmtechnische Darstellung so einrichten, das die automatisch gezeichneten straßenbegleitenen Flächen einen minimalen Abstand zur Linie der Straße haben.

Mit dem Antritt bist du hier falsch. Dafür sind die Kollegen des osm-carto-Projektes zuständig. Aber mit einem Issue (https://github.com/gravitystorm/openstreetmap-carto/issues) dürftest du nur deine Zeit (und die anderer) verschwenden.

OkerJoker · 2017-10-25T08:03:28.000Z

toc-rox:

…

Tolle Signatur

Harald_Hartmann · 2017-10-25T08:33:21.000Z

Oder sieh es mal so: jetzt erkennst du wenigstens noch, dass da etwas fehlt und du das ergänzen / verfeinern kannst. Würde das automatisch gemalt werden, würdest du es nicht mehr sehen und jeder andere, der jetzt selbst rendert sich darüber ärgern, dass da immer noch so eine Lücke ist.

OkerJoker · 2017-10-25T09:07:20.000Z

Ich habe viel größere Flächen, die ich ergänzen kann, zum Beispiel Hof Hackeln.

Außerdem brauchen wir hier dringend einen Nominatim-Experten.

Harald_Hartmann · 2017-10-25T09:18:15.000Z

Gut, aber das besprechen wir ja im anderen Thread. Ich werde dazu auch mal jemanden anschreiben.

Yokr · 2017-10-25T14:59:24.000Z

Weil es hier erwähnt wurde: warum werten die Renderer die width-Angaben eigentlich nicht aus und setzen sie grafisch um? In meinen Laienaugen sollte das nun kein allzu großer Aufwand sein, das Ergebnis könnte aber sehr gut aussehen…

chris66 · 2017-10-25T15:05:24.000Z

Yokr:

In meinen Laienaugen sollte das nun kein allzu großer Aufwand sein,

Doch, ist ein Riesenaufwand.

kreuzschnabel · 2017-10-25T15:06:39.000Z

OkerJoker:

Dies liegt daran, daß die Mapper die Kartendarstellung der Straßen und Wege nicht richtig einschätzen und daher die umliegenden Flächen nicht nah genug an die Straßen und Wege heranziehen.

In OSM geht es darum, ein Modell der Realität zu erfassen und nicht darum, eine schöne Karte zu malen. Deshalb sollten Flächengrenzen in OSM da abgebildet werden, wo sie auch real sind. Es wäre reinstes Mappen für den Renderer, sie absichtlich „zu groß“ zu mappen, nur um im Rendering eine Lücke zu vermeiden.

Was meinst du überhaupt mit „die Kartendarstellung“? Es gibt Hunderte von Karten (wenn’s langt), die aus OSM-Daten erzeugt werden, und jede stellt Straßen so dar, wie sie persönlich es für richtig hält.

Der Renderer kann natürlich versuchen, Lücken automatisch zu schließen. Nur wird er, wenn er deinem Vorschlag folgt, auch dann Grün darstellen, wenn da gar kein Grün ist, sondern etwas anderes Ungemapptes, etwa eine geschotterte Böschung oder eine Wasserfläche. Der Anwender hat dann keine Möglichkeit, festzustellen, ob das Grün gemappt oder geraten wurde. Da sind mir persönlich Lücken lieber.

–ks

Gppes · 2017-10-25T15:29:29.000Z

kreuzschnabel:

OkerJoker:

Dies liegt daran, daß die Mapper die Kartendarstellung der Straßen und Wege nicht richtig einschätzen und daher die umliegenden Flächen nicht nah genug an die Straßen und Wege heranziehen.

In OSM geht es darum, ein Modell der Realität zu erfassen und nicht darum, eine schöne Karte zu malen […] Da sind mir persönlich Lücken lieber.

+1!!!

Die “Angst vor Luecken” hat bei mir auch schon zu vielen Mappingfehlern gefuehrt. Besser mal ein “Platzerl” leer lassen!

maxbe · 2017-10-25T16:24:12.000Z

Ich kann mir irgendwie nicht mal im Ansatz vorstellen, wie man Lücken schliessen könnte, selbst wenn man das wollte… Man müsste

Bei jedem Stück Grün rausbekommen, ob es Strassenrandgrün ist
Die nächste Strasse / Strassenteile suchen (an Kreuzungen und bei Mittelstreifengrün alle Stücke aller beteiligter Strassen)
Schaun, ob nicht noch irgendwas dazwischen liegt (eine Böschung, Mauer, Graben…)
Das Grün bis zu den Strassen ausdehnen

Das ganze bitte performant und weltweit. Ich sehe da grosse Hürden

Yokr:

Weil es hier erwähnt wurde: warum werten die Renderer die width-Angaben eigentlich nicht aus und setzen sie grafisch um? In meinen Laienaugen sollte das nun kein allzu großer Aufwand sein, das Ergebnis könnte aber sehr gut aussehen…

Bis zum Zoomlevel 1415,16 (je nach Geschmack) will man ja die Strassen breiter darstellen, als sie sind. Schliesslich sind die wichtig und sollen eingefärbt und beschriftet werden, und da übermalt man lieber die Häuser links und rechts daneben um Farbe, Schrift und noch einen Rand aufs Bild zu bekommen.

In höheren Zoomleveln könnte man auch die Breite auswerten, müsste dann aber irgendwelche Defaultwerte erfinden, um die Straßen ohne Breite zu malen (nach highway=* oder Anzahl der Spuren oder …). Das wäre ziemlich viel Mühe und ich glaube, es wäre ziemlich hässlich an den (vielen?) Stellen wo Strassenstücke mit width=* mit welchen ohne diese Angabe zusammenstossen. Dann lieber sowas wie im Bayernatlas: Der schaltet bei höheren Zoomstufen auf eine Darstellung der Flächen um.

Grüße
Max

ionr · 2017-10-26T05:59:00.000Z

OkerJoker:

ionr:

Meinst du etwa die Abstände zwischen den Straßenlinien und den Flächen? Sowas wie hier zum Beispiel?

Genau sowas meine ich.

ionr:

… Wird ja ohnehin von jedem Programm anders gemacht (OSM Standard, Cyclemap, Topomap, OSMAnd, Maps.me, Komoot wären gleich 6 populäre Karten, die alle völlig anders rendern) und die Darstellungen werden auch mal geändert. Gezeichnet wird wie es in der Realität ist und niemals für die Darstellung…

Maps.me macht alles grün. Da frage ich mich, warum ich’s bunt mache.

Jedenfalls fallen mir auf OSM Standard diese Lücken auf. Vielleicht könnte man ja die programmtechnische Darstellung so einrichten, das die automatisch gezeichneten straßenbegleitenen Flächen einen minimalen Abstand zur Linie der Straße haben.

In diesem Fall sind die Lücken volle Absicht und der Abstand ist gewollt. Die Straße verläuft nicht exakt mittig zwischen den beiden Grünflächen. Es gibt dort rechts eine Radspur, die mit einer schraffierten Fläche von der Straße teilweise abgesetzt ist, der Straßenverlauf orientiert sich an der Fahrbahnmitte der Autospur. Ein automatischer Abstand wäre da völlig falsch. Es würde mich auch etwas verärgern, wenn das einer “zuklebt” oder automatisch ändert weil es doch etwas Arbeit ist, das so zu zeichnen.

Harald Hartmann:

Bei (kleineren) Forstwegen und Landwirtschaftswegen über Äcker hat man sich durchaus darauf geeinigt, dass diese ein Teil dessen sind, aber eine Verkehrsstrasse ist definitiv kein Teil des Strassen ** begleit** grüns

ADD: also in meiner Gegend (Thüringer Wald) ist überwiegend alles größer Track nicht durch die Waldfläche gezeichnet, sondern da endet die Waldfläche an der Straße

Will dir nicht widersprechen, es ist ja auch so zu bevorzugen. Wollte damit sagen: Es gibt einfach enorm viele Ecken, bei denen es so gemacht wird. Ich habe einfach mal in die Karte gezoomt und habe sofort das hier gefunden: http://www.openstreetmap.org/#map=17/52.16105/9.27041&layers=N So etwas meinte ich damit. Die B83 läuft über eine Scrub-Fläche. Ich machs auch nicht so, gibts aber einfach oft.

firstAid · 2017-10-26T11:27:49.000Z

Hallo zusammen,

ich habe mir jetzt den Thread komplett durchgelesen und wollte dazu auch mal meine Meinung abgeben, da ich einer derjenigen Micromapper bin, welcher Straßenbegleitflächen mappt.

Ich finde den OSM-Ansatz Straßen als “Linie” darzustellen schon vom Ansatz her falsch. Wohl bemerkt, ich rede hier von der Darstellung, nicht von der Erfassung als Solche. Allerdings finde ich es sogar auch bei der Erfassung falsch, die gesamte Straße als eine Linie abzubilden. Imho. wäre es ein besserer Ansatz gewesen, wenn OSM von Anfang an Straßen so gemappt hätte, dass eine Line - also ein Abstraktes geometrisches Gebilde - einen Bewegungsvektor “auf einer Straße” repräsentiert hätte. Flächen, also auch Straßenflächen sind meiner Meinung nach davon getrennt zu betrachten und müssten eigentlich als durchweg als “Area” erfasst werden, mit eben diesen Bewegungsvektoren (z.B. sogar runtergebrochen auf die einzelnen Fahrspuren). Diese Erfassung hätte sehr viele Vorteile und (außer den Aufwand) kaum Nachteile. Routing bleibt dabei komplett von der Flächendarstellung gelöst.

Aber zurück zur Thematik, OSM hat sich anders entwickelt und Straßen sind jetzt halt alles Linien. Aber da OSM sich ständig entwickelt möchte ich das Augenmerk auf die Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area und http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway legen, bei dem es genau um das Thema geht.

Vom Ankleben der Begleit-Flächen an eine abstrakte Straßen"linie" halte ich jedoch nichts - weil es - wie schon erwähnt - vieles an Micromapping-Arbeit einfach zunichte macht, aber dennoch stören auch mich die freien Flächen. Das Problem auf die Renderer abzuwälzen halte ich allerdings auch für komplett falsch - weil meiner Meinung nach besteht bei Straßen ein eklatanter Mangel der Erfassung in OSM selbst (also kann es eigentlich nicht das Problem der Renderer sein, wenn wir Straßenflächen unzureichend erfassen). Eine Straße ist faktisch nun mal eine Fläche und keine abstrakte Linie und da wir mappen was (insbesondere von oben) da ist - müssten wir eigentlich Straßenflächen auch als Flächen mappen, ganz so wie wir es ja auch mit Flüssen machen. (Topologisch genau das gleiche wie eine Straße)

Mit der Erfassung der Straßenbegleitflächen bereite ich genau dies bereits jetzt vor - weshalb dort auch die hässlichen Leerflächen enstehen. Und wenn das area:highway mal irgendwann durch geht - leg ich los und erfasse sämtliche Straßen meiner Umgebung als Area nach.

So der Plan - bis dahin nehme ich dann die Leerflächen als häßliches Übel in kauf.

Harald_Hartmann · 2017-10-26T12:03:57.000Z

firstAid:

Ich finde den OSM-Ansatz Straßen als “Linie” darzustellen schon vom Ansatz her falsch. Wohl bemerkt, ich rede hier von der Darstellung, nicht von der Erfassung als Solche. Allerdings finde ich es sogar auch bei der Erfassung falsch, die gesamte Straße als eine Linie abzubilden. Imho. wäre es ein besserer Ansatz gewesen, wenn OSM von Anfang an Straßen so gemappt hätte, dass eine Line - also ein Abstraktes geometrisches Gebilde - einen Bewegungsvektor “auf einer Straße” repräsentiert hätte. Flächen, also auch Straßenflächen sind meiner Meinung nach davon getrennt zu betrachten und müssten eigentlich als durchweg als “Area” erfasst werden, mit eben diesen Bewegungsvektoren (z.B. sogar runtergebrochen auf die einzelnen Fahrspuren). Diese Erfassung hätte sehr viele Vorteile und (außer den Aufwand) kaum Nachteile. Routing bleibt dabei komplett von der Flächendarstellung gelöst.

kurze Zwischenfrage bzw. Wiederholung in eigenen Worten, ob ich dich da richtig verstanden habe:
Du würdest also auf einer 3 spurigen Autobahn auch 3 Linien bzw. Bewegungsvektoren eintragen? Wie soll dann deiner Meinung nach dann noch der durchaus übliche “Spurwechsel” erfolgen, wenn die 3 Bewegungsvektoren keine Verbindung mehr haben? Bzw. müsstest du ja dann bei einer Ausfahrt noch Bewegungsvektoren von der ganz linken auf die mittlere auf die rechte auf die Ausfahrt ziehen, oder? Würde dann meiner Meinung nach ziemlich “häßlich” mit den “Graphen” … und in dem Falle definitiv die jetzt angewandte Praxis der Abstraktion (1 Bewegungsvektor mit entsprechenden Attributen lanes=3, etc.) bevorzugen.

kreuzschnabel · 2017-10-26T12:13:00.000Z

firstAid:

Diese Erfassung hätte sehr viele Vorteile und (außer den Aufwand) kaum Nachteile.

„außer dem Aufwand“ ist gut. Genau der wäre doch das Problem. Da kannst du dich vielleicht noch mit einer Handvoll ausgebildeter Mapper dransetzen, aber kein Community-Projekt mehr fahren, das bewusst so aufgebaut ist, dass auch Anfänger sich schnell aktiv beteiligen und Wertvolles beitragen können. Solange wir das wollen, muss OSM vor allem einfach bleiben, und dafür nehmen wir diese Minuspunkte in Kauf.

Es fing mit der Idee an, in unorganisierter Community-Arbeit ein Straßennetz der Welt digital abzubilden, damit es eine freie Kartenbasis zum elektronischen Navigieren gibt. Hättest du 2006 einem Mapper erzählt, zehn Jahre später würden 1 m breite Grünstreifen als Polygone gemappt, man hätte dich schlicht für vollkommen durchgeknallt erklärt.

Natürlich ist es nicht schlecht, Straßengrün zu mappen, das meine ich damit nicht. Aber diese Projekte müssen sich jetzt halt in die gewachsenen Strukturen nachträglich einpassen.

–ks

toc-rox · 2017-10-26T13:00:47.000Z

@firstAid: Könntest du das Thema Straßenflächen in einen eigenen Thread auslagern? Ich halte es für recht wichtig.

firstAid · 2017-10-26T18:29:39.000Z

Harald Hartmann:

firstAid:

Ich finde den OSM-Ansatz Straßen als “Linie” darzustellen schon vom Ansatz her falsch. Wohl bemerkt, ich rede hier von der Darstellung, nicht von der Erfassung als Solche. Allerdings finde ich es sogar auch bei der Erfassung falsch, die gesamte Straße als eine Linie abzubilden. Imho. wäre es ein besserer Ansatz gewesen, wenn OSM von Anfang an Straßen so gemappt hätte, dass eine Line - also ein Abstraktes geometrisches Gebilde - einen Bewegungsvektor “auf einer Straße” repräsentiert hätte. Flächen, also auch Straßenflächen sind meiner Meinung nach davon getrennt zu betrachten und müssten eigentlich als durchweg als “Area” erfasst werden, mit eben diesen Bewegungsvektoren (z.B. sogar runtergebrochen auf die einzelnen Fahrspuren). Diese Erfassung hätte sehr viele Vorteile und (außer den Aufwand) kaum Nachteile. Routing bleibt dabei komplett von der Flächendarstellung gelöst.

kurze Zwischenfrage bzw. Wiederholung in eigenen Worten, ob ich dich da richtig verstanden habe:
Du würdest also auf einer 3 spurigen Autobahn auch 3 Linien bzw. Bewegungsvektoren eintragen? Wie soll dann deiner Meinung nach dann noch der durchaus übliche “Spurwechsel” erfolgen, wenn die 3 Bewegungsvektoren keine Verbindung mehr haben? Bzw. müsstest du ja dann bei einer Ausfahrt noch Bewegungsvektoren von der ganz linken auf die mittlere auf die rechte auf die Ausfahrt ziehen, oder? Würde dann meiner Meinung nach ziemlich “häßlich” mit den “Graphen” … und in dem Falle definitiv die jetzt angewandte Praxis der Abstraktion (1 Bewegungsvektor mit entsprechenden Attributen lanes=3, etc.) bevorzugen.

Nein, das wäre ja ein und der selbe Bewegungsvektor. Der sich dann ganz normal an der Abfahrt aufzweigen würde… Genau so wie es ja auch in OSM abgebildet ist Ich will daran gar nichts ändern…

Mit geht es eigentlich nur darum das eine Linie keine Straße repräsentieren kann da Straßen 2D sind und Linen 1D
Ich will schon alles lassen wie es ist Nur eben - wie in dem Proposals vorgeschlagen - für die Darstellung die Straßen als 2D-Flächen mappen, so wie sie in echt eben auch vorhanden sind.

Kreuzschnabel:

@firstAid:

„außer dem Aufwand“ ist gut. Genau der wäre doch das Problem. Da kannst du dich vielleicht noch mit einer Handvoll ausgebildeter Mapper dransetzen, aber kein Community-Projekt mehr fahren, das bewusst so aufgebaut ist, dass auch Anfänger sich schnell aktiv beteiligen und Wertvolles beitragen können. Solange wir das wollen, muss OSM vor allem einfach bleiben, und dafür nehmen wir diese Minuspunkte in Kauf.
Es fing mit der Idee an, in unorganisierter Community-Arbeit ein Straßennetz der Welt digital abzubilden, damit es eine freie Kartenbasis zum elektronischen Navigieren gibt. Hättest du 2006 einem Mapper erzählt, zehn Jahre später würden 1 m breite Grünstreifen als Polygone gemappt, man hätte dich schlicht für vollkommen durchgeknallt erklärt.
Natürlich ist es nicht schlecht, Straßengrün zu mappen, das meine ich damit nicht. Aber diese Projekte müssen sich jetzt halt in die gewachsenen Strukturen nachträglich einpassen.
–ks

Oh da bin ich voll und ganz deiner Meinung (siehe weiter unten die Antwort für toc-rox)
Ich bin damals mit onBoard gewesen als es nur um GPS-Tracks von Straßen ging, bin dann ausgestiegen ungefähr als Häuser dazukamen und steig jetzt wieder ein wo (in gut gemappten Bereichen) erste Leute Micromapping betreiben Daher kenne ich das Phänomen Openstreetmap eigentlich ganz gut Und aus heutiger Sicher ist mal immer schlauer. Es war ja auch niemals falsch so vorzugehen, wie man vorgegangen ist - eben weil es erst mal um die Straßen ging (Street-Map)… Aber mittlerweile hat sich die OSM ja hin zu einer OM entwickelt, bei der alle möglichen Flächen naturgetreu nach-gemappt werden (mein Beispiel mit den Flüssen finde ich da sehr gut). Nur die Straßen (das eigentliche Kernstück) ist irgendwie “Flächentechnisch” untergegangen… Aber ich denke ich werde einen eigenen Thread dafür eröffnen - aber ich brauche ein bisschen Vorbereitung weil ich das gut Formulieren will und insbesondere auch die Kern-Mapper (die mit der Liebe zu Poly-Linen) überzeugen möchte, dass man damit beginnen kann - ohne a) etwas kaputt zu machen und b) OSM damit noch toller zu machen.

toc-rox:

@firstAid: Könntest du das Thema Straßenflächen in einen eigenen Thread auslagern? Ich halte es für recht wichtig.

Oh äh… Ja gerne… da brauche ich allerdings etwas Vorlaufzeit für. Ich dachte allerdings, ich hätte das Thema hier schon mal gelesen Die Suchfunktion spuckt zwar auch was aus - da geht es aber irgendwie um Schlichtungen zwischen Usern wo sich zwar auch die Diskussion darum gedreht hat, aber es ist nicht Intension des OT gewesen ggg

Ich bereite da mal was vor. Imho. finde ich es auch völlig unschädlich das irgendwann mal so zu mappen… da es ja am bestehenden OSM nichts kaputt macht, sondern eigentlich nur komplettiert… Und wenn irgendwann die Datenbasis mal gut genug ist - dann stellen die Renderer darauf um und plötzlich wird es einen Mapping-Boom geben um die Lücken zu füllen, ganz so wie es bei OSM ja schon immer war.

Verbessern kann man doch eigentlich immer irgendwas…