Automatisches Straßenbegleitgrün ....

Noframe · 2017-10-25T06:38:31.000Z

Harald Hartmann:

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

Ach, und ich dachte immer die Straßenbreite wird mit width=* angegeben ?

toc-rox · 2017-10-25T07:01:52.000Z

Noframe:

Ach, und ich dachte immer die Straßenbreite wird mit width=* angegeben ?

Mit area:high wird die Straßenfläche beschrieben und nicht die Straßenbreite. Straßen sind ja in der Realität Flächen und keine Linien.

Harald_Hartmann · 2017-10-25T07:03:58.000Z

Klar, das kann und sollte man zwar auch machen, aber auch das wird von den wenigsten Renderer ausgewertet, und spiegelt sich somit nicht im Kartenbild wieder, aber wenn man unbedingt ein schönes Kartenbild erhalten möchte, ohne tagging for the renderer zu betreiben, bietet sich meiner Meinung nach nur area:highway an…

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.