OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#1 2017-10-28 13:17:21

firstAid
Member
From: Rhein-Neckar-Dreieck
Registered: 2016-02-10
Posts: 80

Straßen (auch) als Flächen mappen...

Hallo zusammen,

Ausgehend von dem Thread Automatisches Straßenbegleitgrün... möchte ich hier einen neuen Diskussionsthread zum Thema Straßen als Fläche mappen eröffnen.

Kurz vor-weg... Das Thema ist schon in der Vergangenheit immer mal wieder in verschiedensten Diskussionen aufgekommen und man findet auch einiges über die Suche. Exemplarisch sind hier mal die beiden Theads verlinkt, Rendering von area:highway und Strassen als Fläche.

Warum also eine neue Diskussion...

Weil ich denke, das dieses "Straßen als Flächen" eines der interessanteren Themen der aktuellen OSM ist und es zudem in der heutige OSM-Community breit gefächerte Meinungen dazu gibt - und ich finde, das dieses Thema deutlich mehr Beachtung verdient.

*tldr - bitte zu "Straßen sind Flächen" springen*

Ganz kurz möchte ich mal meinen eigenen Hintergrund anreißen... Ich selbst bin schon von Anbeginn begeisterter OSM'ler. Ich habe schon recht früh angefangen GPS-Daten zu sammeln und kenne die Map noch aus Zeiten, in denen noch keine Wälder, Felder und schon gar keine Häuser darauf zu sehen waren... Von anderen grauen teilen der Erde mag ich gar nicht erst sprechen ;-) Kurz gesagt, war ich dabei als es bei OSM darum ging vordergründig Straßen zu mappen um a) freies Wissen zu schaffen und b) auf Grundlage diesen freien Wissens tolle Anwendungen zu ermöglichen (z.B. Routing etc.pp.). Zu dieser Zeit war es gar keine allzu große Frage wie man die Straßenzüge mappt, da sich Polylinien als sehr gut geeignetes Instrument ergeben haben. Gerade über die fein graduierbaren Tag-Strukturen kann man damit ein tolles Abbild der Realität gewährleisten und da ein Autofahrer, Fußgänger und Co. sich super als finiter Punkt auf einer Linie darstellen lassen kann man sogar mathematisch viele schöne Dinge (Zeit-Weg-Isolinen / Routing / tollste Auswertungen über Straßenverläufe usw.) damit anstellen. Ich selbst habe mich langsam aus OSM etwas zurückgezogen, da ich weniger Zeit hatte - weshalb ich den richtigen Mapping-Boom auch etwas verschlafen hatte. Zurückgekommen bin ich - zu einer Karte - die weit mehr als eine "Street-Map" war. Eine Karte die mittlerweile gefüllt von allerlei Informationen ist, die sehr gute Qualität haben, aber auch mittlere und weniger gute. Auch die Datendichte hat explosionsartig zugenommen, so dass - fast überall Häuser, Wälder, Flüsse usw. erfasst sind. WOAH DUDE!

Aber - eine Sache wurde beim Gang hin zu einer "OpenSuperMap" konsequent unterschlagen und es hat sogar noch mit dem Kernstück - den Straßen - zu tun. Nachdem der eigentliche Sinn der OSM weitgehend (bis auf die Mühsame tägliche Pflege und das erfassen von neubauten) erfüllt war - und die Straßen so in der Datenbank abgebildet waren, dass wir all die schönen Open-Data-Projekte damit machen konnten, die wir heute haben - haben wir uns zwar der Erfassung von allen nur Erdenkbaren Flächen gewidmet und haben Multipolygonmonster erschaffen die uns heute teilweise Auffressen, haben logische Relationsmoster (die zwar sehr geil sind) erschaffen die es Anfängern fast unmöglich machen ohne Studium der Materie Dinge zu ändern, haben aber eine Sache ganz vergessen und (bewusst) unterschlagen (da darin kein Sinn gesehen wurde). Gerade in den letzten Jahren, in denen wir vielerorts auf hochqualitative Luft/Satbilder zurückgreifen können haben wir nun die Chance bekommen, diesen für mich superlogischen Schritt nachzuholen.

Straßen sind Flächen

Ich bin der Meinung, wir sollten langsam anfangen (für die Daten) und aber auch - oh nein er sagt die bösen Worte - für die Renderer Straßen als Flächen zu erfassen*.

Es gibt hierzu auch ein sehr ausführliches Proposal Proposed features/Street area von dem oben genannten Marek und ein weniger komplexes Proposed features/area:highway", die sich damit schon sehr umfassend befasst haben. Ebenso werden die Proposals in anderen Teilen der Welt (Russland) und sogar in Berlin schon fleißig angewand (danke tox-rox für den Hinweis)

Ich selbst habe mich sehr dem Micromapping von Straßenbegleitflächen verschrieben und da sind diese Überlegungen natürlich für mich Gold, denn wie im Thread von OkerJoker stören mich natürlich auch immer die "weißen Flecken" zwischen den abstrakt gerenderten Straßen und den anhand von Sat-Bildern relativ gut platzierten Straßenbegleitflächen. Topologisch gesehen bin ich strikt gegen ein "ankleben" von Flächen an Linien, auch wenn es durchaus in manchen Situationen absolut Sinn machen kann. Die Straßen würde ich auch gar nicht abschaffen oder ändern wollen, sondern stattdessen "unter den Straßen" die Proposals umsetzen. Also die Flächen auf denen die Straßen liegen konsequent als Flächen zu mappen und somit die Lücken zu den Straßenbegleitflächen zu schließen. Wie viel Vorteile dies hat, geht m.M. nach aus den Proposals hervor... und "kaputt" macht es - so wie ich das sehe - auch nichts. Jetzt lebt aber die Openstreetmap von der diskutierenden Community und deshalb finde ich - bevor jeder wild anfängt - sollte man so ein gewaltiges Vorhaben entsprechend besprechen und diskutieren.... smile

Ich für meinen Teil bereite diese Art von Mapping fleißig vor - da ich meine Straßenbegleitflächen so mappe, dass die Straßenfläche dadurch als leerer Bereich sichtbar wird (die Daten sind somit eigentlich schon erfasst ;-) Beispiel aus meiner Heimatstadt, wo die Straßen sich durch die Begrenzungsflächen bereits jetzt schon abzeichnen (bitte nicht so genau in die Gegend herumgucken - hier ist noch viel Arbeit, auch ohne das ganze Micromapping und "Straßen als Flächen"-Thema :-) - von daher ein eher schlechtes Beispiel, aber eben eines das ich kenne)... Und das kann ich schon an vielen Orten (wo hochqualitative Sat/Lufaufnahmen zur Verfügung stehen) erkennen... Fehlt also eigentlich die letzte Konsquenz die Straßenoberflächen auch als solche in den Daten zu repräsentieren...

- Ich merke, ich schreibe langsam zu viel ... Daher sei mal an euch "Befürworter" und "Gegner" weitergegeben... smile

edit:
* Für die Renderer - Deshalb, weil es wahnsinnig schwierig ist aus Straßenbreiten und Abbiegunsbauvorschriften realistische Straßenoberflächen, insbesondere in Kreuzungs-, Abbiege- oder Parkplatzbereichen zu rendern. Deswegen auch - für diejenigen die später aus "unseren" Daten, Bilder malen wollen ;-)

Last edited by firstAid (2017-10-28 13:24:03)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#2 2017-10-28 15:35:55

Lukas458
Member
From: Wuppertal
Registered: 2017-05-01
Posts: 66

Re: Straßen (auch) als Flächen mappen...

Grundsätzlich finde ich die Idee sehr gut. Insbesondere da ich aus deinem Text herauslese, dass die Straße - Flächen die bestehenden Straße - Linien ergänzen sollen und diese eben nicht ersetzen sollen. Letzteres ist nämlich meiner Ansicht nach nicht möglich. Ich wäre dafür, Straßen-Flächen zunächst als zusätzliches Detail-Mapping anzunehmen und die Flächen aber glaube ich besser von jeder Routing-Intention fernzuhalten. Oder kennt jemand einen Router, der mit Areas vernünftig umgehen kann? Ich würde mir wünschen, dass man an die Flächen dann auch nicht das ganze maxspeed und access-Gedöns und so weiter tagt, denn ansonsten wird es zu kompliziert wenn wir neben Linien auch noch Flächen ständig aufteilen müssen. Für mich ist klar, dass Linien weiterhin alles übernehmen sollten, was mit Bewegung entlang einer Route zu tun hat. Wie sehen andere das?
Und denkt immer daran:
In fast jeder Stadt in OSM gibt es bereits "Straßen"-Flächen: Die Fußgängerzonen. Das sind für mich die Pioniers-Objekte im Flächenkartieren von highways. Trotzdem könnte man das Flächenkartieren vielleicht zunächst auf größere Straßen begrenzen? Und was macht man eigentlich bei Tunnelflächen? Also wenn das flächendeckend etwas werden soll, dann müssen sich die Renderer dringend was überlegen. Z. B. wenn man eine Straßen-Fläche hat, und darüber ein überbrückendes Gebäude. Bisher liegt highway immer höher als building. Da könnte es Probleme geben, denkt nur an railway= platform und Gebäude drüber. Egal, was du mit welchem Layer versiehst, platform liegt immer über building. Was ich damit sagen will ist: Immer dort, wo viel "Flächiges" zusammenkommt, wird's schwierig wink


Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Freundliche Grüße!

Offline

#3 2017-10-28 16:36:00

krza
Moderator
From: Köln
Registered: 2008-05-24
Posts: 624
Website

Re: Straßen (auch) als Flächen mappen...

Hm. Ich kann die Beweggründe gut nachvollziehen, insbesondere mit Blick auf die sog. Begleitflächen. Allerdings halte ich im ersten Moment wenig davon, jede einfache Straße mit einer Fläche zu unterlegen. Vielmehr geistert seit Jahren die Idee in meinem Kopf herum, die Breitenangaben der Straßen anders zu machen als im Moment.

Derzeit werden ja ways mit einer Breite versehen. Das führt aber dazu, dass man wechselnde Straßenbreiten nur schwer gemappt bekommt und dass es lauter Brüche gibt. Viel sinnvoller wäre es, die Breitenangabe an way-nodes zu machen, denn das käme auch der realen Datenerfassung viel näher, bei der man ja die Straßenbreiten an Stützstellen ermittelt. Zwischen diesen kann dann auch bruchfrei interpoliert werden. Vorteil ist auch, dass man einen way nicht aufteilen muss, um unterschiedliche Breiten zu applizieren.

Im Grunde werden Breitenangaben beim Spurmapping ja schon umgesetzt beim Rendern, aber leider nur in bestimmten Editoren wie JOSM, und da nur in den Plugins. Ansonsten würde das aber das Problem eigentlich schon lösen, ohne durch zusätzliche Flächen-Elemente unnötig zusätzliche Daten zu erzeugen, die die ohnehin teilweise schon schwer zu durchschauenden Daten noch unübersichtlicher machen.

Ich gebe zu, dass mein Ansatz teschnisch und datentechnisch zwar der bessere wäre, aber dass er natürlich ohne ein echtes Messen schwer umzusetzen ist. Eine Fläche anhand von Bildern zu "malen" ist hingegen viel einfacher. Naja ... man muss sich entscheiden wink

Offline

#4 2017-10-28 16:48:20

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

krza wrote:

Ich gebe zu, dass mein Ansatz teschnisch und datentechnisch zwar der bessere wäre, aber dass er natürlich ohne ein echtes Messen schwer umzusetzen ist. Eine Fläche anhand von Bildern zu "malen" ist hingegen viel einfacher.

So isses. Und OSM müssen wir einfach halten, wenn wir ausreichend Mapper behalten wollen. Ansätze, die datentechnisch sauberer wären, aber mit viel mehr Aufwand verbunden, gehen nur in entsprechend qualifizierten Arbeitsgruppen.

Dabei schließt das eine ja das andere nicht aus, es ließe sich technisch übersetzen. Anhand der vom Mapper als Polygon gemappten Straßenränder kann der Editor ja die Breite an jedem Node des Straßen-Ways ermitteln (orthogonal zur Straßentangente) und in die Datenbank schreiben, also das Polygon selbst gar nicht hochladen, sondern die daraus eruierten Breitenwerte der Linienway-Nodes. Die der nächste Editor dann auswertet und wieder als virtuelles Polygon darstellt smile

Aber die Lösung als area:highway-Polygone in der Datenbank ist auch nicht schlecht.

--ks


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#5 2017-10-28 17:00:48

krza
Moderator
From: Köln
Registered: 2008-05-24
Posts: 624
Website

Re: Straßen (auch) als Flächen mappen...

Stimmt, diese automatische Übersetzung klingt auch nicht schlecht. Komplizierter als einfaches "Abmalen" bleibt es aber. Und am Ende können beide Lösungen auch nebeneinander existieren bzw. alle drei: Flächen, Knotenbreiten und Segmentbreiten.

Offline

#6 2017-10-28 17:10:20

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 7,878

Re: Straßen (auch) als Flächen mappen...

Tsst, "Knotenbreiten". Punkte haben normalerweise keine Breite.
Schwierig wird's insbesonders wenn sich mehrere ways an einem Node treffen.


Mapper aus NRW/Münsterland mit 10-jähriger Erfahrung.

Offline

#7 2017-10-28 18:14:37

krza
Moderator
From: Köln
Registered: 2008-05-24
Posts: 624
Website

Re: Straßen (auch) als Flächen mappen...

Manchmal muss man die Theorie auch ein bisschen dehnen, um der Realität gerecht zu werden. Knoten-Eigenschaften muss man in diesem Sinne nicht unbedingt als Eigenschaften dieser Knoten selbst, sondern als Eigenschaft des Knotens in seiner Eigenschaft als Staßenknoten sehen. Dann kommt man auch um diese vermeintliche Klippe herum.

Das mit den Kreuzungen stimmt, aber dafür braucht es dann entweder eine Zuordnung zum richtigen Weg per Relation (wird anderswo auch gemacht, z.B. bei Abbiegerelationen), oder aber es gibt die Regel, dass Kreuzungspunkte keine Breite haben dürfen. Dann ist nämlich alles gut.

Offline

#8 2017-10-28 22:40:08

Rogehm
Member
From: Rösrath / Köln
Registered: 2014-05-07
Posts: 2,062

Re: Straßen (auch) als Flächen mappen...

Na ja,
Ich finde ein solche alternative Ansicht der OSM, obwohl im Rendering noch verbesserungswürdig, sehr schön. Das Erfassen von Strassenbreiten als Fläche kann NUR aus der Sicht von oben erfolgen mittels area:highway (das sehr gut durchdacht ist), niemals mit irgendwelchen Knoten, da eine Straße und deren Begleitelemente wie Parknischen, Verkehrsinseln, Spuränderungen, Fußgängerüberwege, Sperrflächen niemals damit erfasst werden kann. Das Routing erfolgt immer über die Linie, was sich keineswegs widerspricht. Ich finde es nur schade, das sich Marek aus dem Projekt verabschiedet hat, obwohl es sehr zukunftweisend ist. Denn seit dem tut sich nicht mehr viel in Punkte Serverunterstützung für das Projekt. Ich würde es weiter unterstützen, wenn auch in NRW gerendert würde.


Gruß   Rolf
“Ich kann freilich nicht sagen, ob es besser wird, wenn es anders wird. Aber soviel kann ich sagen: es muss anders werden, wenn es besser werden soll!”  Georg Christoph Lichtenberg (1742-1799)

Offline

#9 2017-10-28 22:55:05

Galbinus
Member
From: Ostwestfalen-Lippe (OWL)
Registered: 2016-10-05
Posts: 203

Re: Straßen (auch) als Flächen mappen...

Rogehm wrote:

Na ja,
Ich finde ein solche alternative Ansicht der OSM, obwohl im Rendering noch verbesserungswürdig, sehr schön.

Naja, wenn man das weiterdenkt, könnte man gleich Satelitenbilder statt Karten nehmen. Eine Karte soll und muss die Wirklichkeit vereinfachen und pauschalisieren und so eine Orientierung ermöglichen. Dafür scheint mir das klassische Kartenbild mit Straßen in Farbe und Breite entsprechend ihrer Verkehrsbedeutung geeigneter als eine möglichst reale Abbildung der tatsächlichen Breite.

Offline

#10 2017-10-29 00:27:44

Rogehm
Member
From: Rösrath / Köln
Registered: 2014-05-07
Posts: 2,062

Re: Straßen (auch) als Flächen mappen...

Galbinus wrote:

Naja, wenn man das weiterdenkt, könnte man gleich Satelitenbilder statt Karten nehmen. Eine Karte soll und muss die Wirklichkeit vereinfachen und pauschalisieren und so eine Orientierung ermöglichen.

Im Prinzip hast du Recht. Aber die OSM ist keine Karte. Sondern eine Geo-Erfassungsdatenbank und sollte sich den Satellitenbildern angleichen, und das möglichst detailgetreu. Und wenn im erlaubten SAt-Bild genaue Flächen der Strassen erkennbar sind, spricht nichts dagegen, dies auch in der OSM zu erfassen.
Edit: Das Routing erschließt sich natürlich zum althergebrachten Linie einer Straße, aber die vor Ort Orientierung kann durchaus mit dem Flächentagging genau dargestellt werden. Das bedeutet auch z.B. Parkstreifen, Randstreifen, Schutzstreifen,  für PKW/LKW Parkmöglichkeiten, Ausweichstellen u. v. m.

Last edited by Rogehm (2017-10-29 00:49:00)


Gruß   Rolf
“Ich kann freilich nicht sagen, ob es besser wird, wenn es anders wird. Aber soviel kann ich sagen: es muss anders werden, wenn es besser werden soll!”  Georg Christoph Lichtenberg (1742-1799)

Offline

#11 2017-10-29 02:06:13

slhh
Member
Registered: 2012-09-02
Posts: 323

Re: Straßen (auch) als Flächen mappen...

Grundsätzlich halte ich es für sinnvoll, Flächeninformationen für die Straßen zu erfassen, was aber nicht heißen soll, dass wir alle Straßen als Flächen zeichnen sollten. Wenn wir Flächeninformationen erfassen sollten wir auch Informationen über die Fahrspurlage erfassen. Die genannten Proposals enthalten sicherlich einige sinnvolle Ideen, aber insgesamt halte ich sie aus folgenden Gründen für Murks:

- Sehr einseitig darauf ausgelegt ein bestimmtes Rendering einfach zu machen.
- Flächeninformationen, die anders erfasst werden können oder erfasst sind, z.B. durch width Tags, werden ignoriert.
- Kein Konzept zur Erfassung der Spurlage vorhanden und auch strukturell für eine derartige Erweiterung wohl ungeeignet.
- Doppelte Datenerfassung z.B. bei den Highway-Klassen.

Mein Ansatz zur Flächenerfassung der Fahrbahn wäre wie folgt:

- Flächendaten werden primär am Weg als Breiten, Spuranzahlen etc. getaggt.
- Nur wo es Abweichungen gibt wird zusätzlich der Bordstein oder ein sonstiger Fahrbahnrand als Linie erfasst, wobei zu definieren ist, dass die Fahrbahn z.B. immer links von der Linie liegt.

Das Rendering erfolgt dann so:
- Es wird ein Schlauch in um den Highway in der Anhand der Tags bestimmten Breite und Lage um den Highway gebildet.
- Wird in diesem Schlauch eine Fahrbahnrandlinie gefunden, wird die Breite bis zu dieser reduziert.
- Zusätzlich ist von allen Fahrbahnrandlinien alles was links liegt bis zum nächsten Highway als Fahrbahnfläche zu rendern.

Offline

#12 2017-10-29 03:01:16

firstAid
Member
From: Rhein-Neckar-Dreieck
Registered: 2016-02-10
Posts: 80

Re: Straßen (auch) als Flächen mappen...

Hallo zu später Stund, ich bin gerade noch ein wenig mappend unterwegs und auf ein - wie ich denke - super Beispiel getroffen, wie ein realer Sachverhalt - zwar mathematisch einfach und korrekt abgebildet ist - aber mit der Realität (Sat-Bild) eigentlich nur wenig zu tun hat - und jeder der sich die Karte ausdrucken würde wäre völlig verwirrt  :-)

q4wW5S9.jpg
http://www.openstreetmap.org/edit#map=2 … 56/8.55678

Wenn man dem Link mal folgt und sich das ganze mal mit Bing-Hintergrund ansieht, weiß sofort was ich damit sagen will... Dadurch das wir bisher die Straßen "nur" als Linien erfasst haben, haben wir uns solche Konstrukte gezüchtet, die meiner Meinung nach mit dem realen Abbild einer Kreuzung nichts mehr zu tun haben und nur noch aus Datensicht korrekt sind.

Am liebsten würde ich das ganze Dingens neu machen... Aber solange die Renderer die Straßen als "Linien" rendern, muss man meiner Meinung nach bei dieser komischen 5er-Kreuzung bleiben. Wenn wir aber anfangen würden die Straßen als Flächen zu mappen, und die Renderer dann irgendwann in ferner Zukunft mal darauf umstellen... ist so eine Datenbasis (in meinen Augen) kein Problem mehr - da die abstrakte Polylinienkonstruktion dann so bleiben kann (auch wenn ich die Abbiegespuren dennoch anders machen würde, alleine schon damit Navi's nicht erst 1m vor der Kreuzung anfangen das Bild wild zu drehen ;-)

P.S. Ich habe mir noch nicht alle Antworten durchgelesen und wollte das nur mal kurz einwerfen, weil es mir gerade aufgefallen ist!


----
Für die Daten, nicht für die Renderer! :-)

Offline

#13 2017-10-29 08:53:11

Galbinus
Member
From: Ostwestfalen-Lippe (OWL)
Registered: 2016-10-05
Posts: 203

Re: Straßen (auch) als Flächen mappen...

firstAid wrote:

Wenn man dem Link mal folgt und sich das ganze mal mit Bing-Hintergrund ansieht, weiß sofort was ich damit sagen will...

Ich persönlich finde an dem Beispiel nichts Verwirrendes. Solange alle Spuren zusätzlich per lanes korrekt erfasst sind, dürfte auch für Navis mit Spurassistent alles gut funktionieren. Für die Navigation per Kartenbild (wenn ich z.B. mein kleine Garmin Handteil für die Autonavigation nutze) ist das genau das Kartenbild, was mir die Orientierung ermöglicht.
Eine Darstellung als Flächen wäre da für mich nicht wirklich hilfreich.
Aber natürlich ist die Darstellung als Flächen eine feine Sache für den Detailbereich. Wird ja z.B. bereits für Fußgängerzonen genutzt.

Offline

#14 2017-10-29 09:50:30

ionr
Member
Registered: 2015-08-08
Posts: 52

Re: Straßen (auch) als Flächen mappen...

firstAid wrote:

Hallo zu später Stund, ich bin gerade noch ein wenig mappend unterwegs und auf ein - wie ich denke - super Beispiel getroffen, wie ein realer Sachverhalt - zwar mathematisch einfach und korrekt abgebildet ist - aber mit der Realität (Sat-Bild) eigentlich nur wenig zu tun hat - und jeder der sich die Karte ausdrucken würde wäre völlig verwirrt  :-)

https://i.imgur.com/q4wW5S9.jpg
http://www.openstreetmap.org/edit#map=2 … 56/8.55678

Wenn man dem Link mal folgt und sich das ganze mal mit Bing-Hintergrund ansieht, weiß sofort was ich damit sagen will... Dadurch das wir bisher die Straßen "nur" als Linien erfasst haben, haben wir uns solche Konstrukte gezüchtet, die meiner Meinung nach mit dem realen Abbild einer Kreuzung nichts mehr zu tun haben und nur noch aus Datensicht korrekt sind.

Ein Navi wird mich hier aber sauber drüber leiten, mit Spuranzeige. Das wird bei Linien immer etwas kompliziert abzubilden sein. Ich stelle aber doch die Frage, wie das mit Straßenflächen sauberer gehen soll, denn es müssen Informationen vorhanden sein, welche Straßenflächengrenze für welche Linie gilt. Die Routing- und Spurinformation durch einen Rechner von der Linie auf eine Fläche zu übertragen halte ich für sehr "herausfordernd", da wäre es vllt einfacher, width vom Renderer zu nutzen.

Man könnte bei diesem Beispiel vielleicht den Kurvenverlauf etwas nachzeichnen und die Abzweige der Verbindung hinter die durchgezogene Linie setzen (Spurwechsel ist hier nicht mehr erlaubt). Die Punkte, bei denen das Lanes-Schema den Beginn der Abbiegespur angibt, könnten weiter von der Kreuzung weg, da die Spur etwas früher anfängt.

Also von vorher:
2017-10-29-kreuzung1t.png

Zu jetzt, nachher:
2017-10-29-kreuzung2t.png

Hochgeladen hab' ich das jetzt nicht. So könnte das ganze jedoch etwas Realitätsgetreuer dargestellt werden, ohne Flächen zu nutzen. Allein die width=-Information der Fahrspuren würde schon reichen, die Kreuzung "schöner" zu rendern, das JOSM-Plugin mit den Spuren kann es ja auch.

Offline

#15 2017-10-29 10:32:28

Galbinus
Member
From: Ostwestfalen-Lippe (OWL)
Registered: 2016-10-05
Posts: 203

Re: Straßen (auch) als Flächen mappen...

Es ist gut, dass Du das nicht hochgeladen hast. Der aktuelle Diskussionssstand ist, dass erst ab baulicher Trennung die Linien aufgeteilt werden und in einem solchen Fall als Kompromiss an der Stelle, wo sich die eine Spur von der andern wegbewegt (also Beginn der Sperrfläche). Dei durchgezogene Linie kann über die Landes-Attribute für eine Naviauswertung auswertbare Weise dargestellt werden.

Offline

#16 2017-10-29 11:14:02

ionr
Member
Registered: 2015-08-08
Posts: 52

Re: Straßen (auch) als Flächen mappen...

Etwas OT:

Galbinus wrote:

Es ist gut, dass Du das nicht hochgeladen hast. Der aktuelle Diskussionssstand ist, dass erst ab baulicher Trennung die Linien aufgeteilt werden und in einem solchen Fall als Kompromiss an der Stelle, wo sich die eine Spur von der andern wegbewegt (also Beginn der Sperrfläche). Dei durchgezogene Linie kann über die Landes-Attribute für eine Naviauswertung auswertbare Weise dargestellt werden.

Wäre nett, solche Infos greifbar im Wiki zu haben, sodass man hier nicht derart unangenehm aufläuft. Dann entsprechen viele Autobahnabfahrten und Kreuzungen, die ich als Referenz genutzt habe, auch nicht dem "aktuellen Diskussionsstand". Solche Infos über solche Ecken im Forum zu bekommen (nicht falsch verstehen, ich fühle mich nicht angegriffen) und nicht bei Bedarf greifbar zu haben, kann ja nur zu inkonsitenten Daten führen roll

Wenn dieser aktuelle Diskussionsstand Dir bekannt ist, wäre es hilfreich, diesen (am besten mit Beispielen) auch irgendwo nachlesbar zu haben und bei Bedarf darauf zu verweisen. Mir nutzt das sonst nichts. Es ist sonst extrem schwer überhaupt zu wissen, was richtig ist und was falsch und was nur "Ansichtssache" ist.

Last edited by ionr (2017-10-29 11:17:00)

Offline

#17 2017-10-29 11:44:19

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

Galbinus wrote:

dass erst ab baulicher Trennung die Linien aufgeteilt werden und in einem solchen Fall als Kompromiss an der Stelle, wo sich die eine Spur von der andern wegbewegt (also Beginn der Sperrfläche).

… und das in einer sauber ausgerundeten Kurve, die der Fahrlinie entspricht, und nicht erst in einem 45°-Winkel weg und dann gleich nochmal soviel zurück auf fast parallel.

--ks


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#18 2017-10-29 11:48:07

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

ionr wrote:

Wenn dieser aktuelle Diskussionsstand Dir bekannt ist, wäre es hilfreich, diesen (am besten mit Beispielen) auch irgendwo nachlesbar zu haben und bei Bedarf darauf zu verweisen.

en-Wiki, Thema Autobahnanschlüsse:

This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn.

Also: Den Trennungsnode an den letztmöglichen Punkt vor der richtungsmäßigen Trennung setzen, aber so, dass noch eine elegante Kurve möglich ist (also kein harter Winkel sein muss).

--ks


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#19 2017-10-29 11:56:53

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

Bei mir sähe das Teil so aus (auch noch nicht hochgeladen):

kreuzung.png

Den Rechtsabbiegerampen noch ein placement=left_of:1 verpasst, dann stimmt sogar die Lage.

--ks


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#20 2017-10-29 12:09:19

firstAid
Member
From: Rhein-Neckar-Dreieck
Registered: 2016-02-10
Posts: 80

Re: Straßen (auch) als Flächen mappen...

Es ist gut, dass Du das nicht hochgeladen hast.

Das finde ich auch gut, dass ganze Thema darf eines nämlich auf keinen Fall - vorschnell und übereilt angegangen werden.
Deswegen ändere ich ja auch nichts daran sondern bin der Meinung das wir hier mal diskutieren sollten... Und wie du und ich ja schon geschrieben haben... Technisch ist daran gar nichts auszusetzen. topologisch absolut ok gemappt...

Nur... Nach meiner Erwartungshaltung die ich an eine Karte habe, wird hier die Realität auf der Karte nicht so abgebildet wie sie ist (und das ist immer mein persönlicher Anspruch an die von mir erfassten Daten)

Als Vergleich hier mal Google https://www.google.de/maps/@49.5115861,8.5566614,19z und Falk https://www.falk.de/maps?gs=falkOrigina … 7190&gz=16

Bei Google sieht die Kreuzung zwar aus meiner Sicht erstmal realitätsgetreuer aus, da sie nicht diesen komischen 5-Stern in der Mitte hat, aber der Kniff ist, das Google einfach schon bei Sperrflächen anfängt zu trennen, nicht erst bei der baulichen Trennung (imho. finde ich dass sogar in vielen Fällen besser)...

Und Falk hat die meiner Meinung beste Ansicht, wenn ich eine reine Straßenkarte haben möchte... Einfach eine Kreuzung zwischen 2 Straßen... Ohne gedöns... Aber halt auch nur gut wenn ich einen groben überblick über den Verlauf der Straßen will... Wenn ich wissen will, wo die Fußgänger hin können, bringt mir sowas nichts.

Und die OSM ist eben nicht mehr nur eine einfache Straßenkarte (so wie die Falk-Karte) :-) sondern mittlerweile eher wie ein CAD-Abbild einer Satellitenansicht, was aus meiner Sicht auch sehr gut so ist und überhaupt erst den echten Endusermehrwert ausmacht (Die Daten interessieren ja nur uns Interessierte). Und die ganze Arbeit die in den Polygonlinen steckt, war/ist auch gut und wichtig - eben weil man damit supertoll Routen berechnen kann. Nur im Moment haben die Renderer gar keine Chance es anders zu machen - Die Width-Tags auszulesen halte ich für sehr schwierig und Falsch, da sie nur eine Kenngröße darstellen. Ich jedenfalls habe noch keine Straße entdeckt, bei der sich die Breitenangabe an jedem Knick und auf Ganzer länge immer überall korrekt ändert, das könnte auch niemand erfassen, bzw. wäre es viel mehr Aufwand das zu erfassen, als diese Informationen z.B. aus Area-Flächen automatisch zu errechnen! Straßen sind eben in der Realität keine "plattgewälzten" symmetrischen Linien, sondern sie sind Asymmetrisch und mal rechts ein bisschen bauchig, mal links einen Meter Breiter, damit man besser abbiegen kann... In Kurven mal ein bisschen breiter, damit man besser um die Kurve kommt (Serpentinen)... Das kann man alles mit Linien-Tags gar nicht darstellen.

Mein Parade-Beispiel ist immer ein Fluss. Einen Fluss mappen wir grundsätzlich als Area. Wenn jetzt ein Fluss in den anderen fließt und im Delta herummeandert, mappen wir für gewöhnlich jeden einzelnen Meander (schreibt man das so? :-) ) als Fläche. Die Flussmitten jedoch haben ihre Polyline... wie z.B. hier beim Rhein http://www.openstreetmap.org/way/830156 … 436/6.6093... Die Koexistenz zwischen Wasserfläche und "Linie" ist hier irgendwie völlig normal und keiner Hinterfragt es groß... Aber bei Straßen schon?! das Verstehe ich dann irgendwie nicht so ganz.

Angenommen die Kreuzung wäre mit Areas gemappt... und die Renderer würden auf das System irgendwann wechslen. Dann sähe die Kreuzung aus wie sie in der Realität ist. Die Spuren könnten dann dort getrennt werden, wo es in der Realität sinn macht. So wie es jetzt abgebildet ist würde man - wenn man sich exakt an die Linien hält in jeder Kurve eine durchgezogene Linie überfahren und bekommt Probleme mit der StVo..., wenn die Standart-Ansicht aber Flächen rendert, sind die Daten nicht mehr zwangsläufig an solche Dogmen gebunden wie "Wir trennen nur wo baulich getrennt ist" ... sondern dann kann man davon - wo es sinn macht auch abweichen. Z.B. um nicht über durchgezogene Linien geroutet zu werden... Die Kartenansicht - bleibt dann - von so etwas unberührt, da sie auf den Areas beruht.

Analog zum Flussmodell ... Wenn Rhein jetzt irgendwo unter Wasser ne Sandbank hätte, dann müsste man die "Fahrspur" des Schiffes auch entsprechend anpassen und um die Sandbank herumleiten... Die Ansicht des Flusses sollte sich dabei aber nicht ändern, da der von oben Betrachtet immer noch das gleiche Bild zeigt.

Ich glaube dass sich highways-Area und Polylinien ergänzen und nicht gegeneinander stehen sollten!

@slhh

Deinen Beitrag fand ich sehr gut... vielleicht taucht Marek ja auch noch in diesem Thread auf... Aber das ist konstruktives herangehen an die Sache... Deinen Ansatz hingegen halte ich für falsch, da ich ganz massiv gegen

Flächendaten werden primär am Weg als Breiten, Spuranzahlen etc. getaggt.

bin. Warum? Weil es eine wahnsinnige Arbeit bedeutet die alles bisher dagewesen bei weitem übersteigt... In welchem Abstand soll man die Straßenbreiten den Messen gehen, in 50m Stücken, in 5m Stücken...? Wenn ich alleine an die Ortsstraße vor meiner Haustüre denke, ergibt sich bestimmt auf 2km Länge 300-400 mal eine Breitenänderung im Bereich von 1-2m. Wer soll das auf diese Weise erfassen? Und wenn ich die Daten aus den Satellitendaten ermessen muss, dann habe ich die Area deutlich schneller abgezeichnet und kann einen OSM-Mathematiker dransetzen, der mir dann die Breite an jeder Stelle aus dem Polygon errechnet.

- Es wird ein Schlauch in um den Highway in der Anhand der Tags bestimmten Breite und Lage um den Highway gebildet.

Das dürfte sehr merkwürdige Ergebnisse bei asymmetrischen Straßenverläufen ergeben, da der Schlauch ja immer von der idealisierten Mitte aus betrachtet wird. Wenn die Straße jetzt aber nur Rechts breiter ist (z.B. in der Kurve einer Serpentine) wird die Straße aber nach deiner Methode überall gleich breiter. Und das dürfte dann sehr merkwürdig aussehen.

Last edited by firstAid (2017-10-29 12:14:13)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#21 2017-10-29 12:27:12

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

firstAid wrote:

wenn man sich exakt an die Linien hält in jeder Kurve eine durchgezogene Linie überfahren und bekommt Probleme mit der StVo...

Dieser Kritikpunkt geht ins Leere. Die Linien sind ja niemals nicht zum exakten Nachfahren gedacht, sondern sind Abstraktionen möglicher Fahrtrouten. Jede Linie – nehmen wir mal die von Osten kommende – steht dabei für die gesamte Straße mit sämtlichen Spuren. Der Punkt, an dem die Rechtsabbiegerampe im Datenmodell vom durchgehenden Way abzweigt, ist mitnichten der Punkt, an dem sich der Fahrer von der Straßenmitte wegbewegt, sondern ist der Punkt, an dem die Rechtsabbiegespur (die ja im lanes:=* und turn:lanes=* des von Osten kommenden Ways enthalten ist!) in eine eigene Fahrbahn übergeht. Da muss niemand eine durchgezogene Linie überfahren, denn auf der Rechtsabbiegespur ist er ja schon. Nur muss dieser Punkt zwangsläufig (da auf der Linie liegend, die die gesamte Straße repräsentiert) in der Straßenmitte liegen und nicht am rechten Rand, wo er einklich hingehört. Das in eine tatsächlich abzufahrende Linie „umzurechnen“ wäre Sache eines Routers, was er sogar lagegenau leisten kann, wenn er lanes:=* und width:lanes=* hat.

--ks


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#22 2017-10-29 12:40:01

krza
Moderator
From: Köln
Registered: 2008-05-24
Posts: 624
Website

Re: Straßen (auch) als Flächen mappen...

Hm. Hier kommt man mit dem Anworten ja gar nicht hinterher ...

Ich wollte gerade mitteilen, dass ich den Ansatz von slhh in #11, den firstAid in #20 ablehnt, ziemlich richtig finde, weil er genau meiner Denke entspricht. Auf der anderen Seite kann ich die Gedanken von Dir, firstAid, zu großen Teilen nachvollziehen und unterstützen. Das Problem "wie oft messe ich dann" bezüglich der Straßenbreiten sehe ich übrigens genauso wenig wie bei der Frage, wann ich einen neuen Punkt setze, um eine Kurve gut abzubilden: Man macht es einfach so oft, wie es notwendig ist. Bei bestimmten Straßenverläufen ist es häufiger, bei anderen weniger häufig. Das sehe ich als kein Problem an, zumal, wenn man im Editor das gerenderte Ergebnis direkt sehen kann (wie bei Fahrspuren), sich also sukzessive an die ideale Knotenanzahl herantasten kann.

Die Geschichte mit dem Fluss  ... ja, da könnte man sicher Parallelen ziehen. Allerdings gibt es auch ein paar mehr Straßen als Flüsse ... Naja, und ich pendele auch  immer im Spannungsfeld zwischen "vielen geometrisch richtigen Daten" und "wenigen komprimierten Daten", die aber die gleiche Information beinhalten, hin und her. Beides hat Vor- und Nachteile, die leider oft auch geschmacks- oder anwendungsabhängig sind.

Ein gutes Beispiel sind die Fahrspuren. Leider gibt es ja dieses o.g. Dogma mit der baulichen Trennung. Hier würde ich mich so weit aus dem Fenster lehnen und behaupten, dass es eigentlich überholt ist. Es entstand halt zu einem Zeitpunkt, als man es noch zur sauberen Datendarstellung brauchte und gar keine Möglichkeit hatte, so detailier zu mappen wie heute. Ich habe jedenfalls bei Kreuzungen und dergleichen immer wieder Schwierigkeiten damit und würde mir wünschen, dass man – wenn nötig (und nur dann) – von dieser Regel abweichen könnte. Das würde im Zweifel darauf hinauslaufen, dass man jeden Fahrstreifen einer Kreuzun mit einem eigenen Way mappt. Ich sehe vor meinem geistigen Auge, wie manchen die Haare zu Berge stehen wink Aber was soll´s – falls es gewichtige Argumente gibt, das Dogma aufrecht zu erhalten, dann bleibt es. Ansonsten muss man gucken, wie man neue Lösungen schafft.

Achso, nur noch ein Punkt zum Beispiel oben (OT): Ampeln machen auch immer Spaß. Wenn man welche setzt wie z.B. die in den Abbiegespuren, dann muss man sie auch so taggen, dass sie nur für den Weg gilt, für den sie eben gilt. Denn sonst bekommt man beim Abbiegen plötzlich eine Ampel vorgesetzt, die gar nicht für einen selbst relevant ist. Zum Beispiel. Habe mir die Daten nicht angeguckt, weiß also nicht, ob es da so oder so ist.

Übrigens ... nicht falsch verstehen, aber wir schreiben hier manchmal so locker, flockig von Dingen, die abgestimmt werden müssten und dass man das dann mal in eine Wiki schreibt undso ... nur sollten wir im Hinterkopf behalten, dass wir hier nicht der Nabel der OSM-Welt sind und es auch noch andere User gibt auf dieser Welt wink DIe Proposal- und Abstimmungsprozesse hatte ich ja schon mal angesprochen letztens.

Offline

#23 2017-10-29 12:47:23

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 2,862

Re: Straßen (auch) als Flächen mappen...

krza wrote:

Das würde im Zweifel darauf hinauslaufen, dass man jeden Fahrstreifen einer Kreuzun mit einem eigenen Way mappt.

Mit der üblichen Frage: Woher weiß der Router, dass die Fahrspur beliebig gewechselt werden kann? Momentan gehen ja die Router bei parallel unverbunden verlaufenden Ways davon aus, dass das nicht möglich ist – wo heute Fahrspuren einzeln gemappt sind, geht der Router, der seinen Nutzer auf einer Geradeausspur ortet, obwohl rechts abgebogen werden muss, davon aus, dass die Abzweigung verpasst wurde, und wird bereits eine Umleitung suchen. Was wieder den Nutzer verwirrt: Nanu, eben sollte ich noch rechts abbiegen, jetzt auf einmal geradeaus?

Das ließe sich beispielsweise über Fahrbahnrelationen lösen, in denen man die „wechselfähigen“, zu einer Fahrbahn gehörenden Spuren zusammenpackt. Prinzipiell habe ich nichts dagegen, weil Geometrien sich dann viel schöner abbilden lassen und vor allem die furchtbaren turn-Relationen dann nicht mehr gebraucht werden, um Fahrspuren von einem Way zum anderen fortzusetzen.

--ks

Last edited by kreuzschnabel (2017-10-29 12:49:54)


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mein OSM-Tutorial auf Deutsch

Offline

#24 2017-10-29 12:51:23

krza
Moderator
From: Köln
Registered: 2008-05-24
Posts: 624
Website

Re: Straßen (auch) als Flächen mappen...

Ja, Du hast Recht, eine Abkehr von dieser Regel würde eine Menge Arbeit bedeuten, ggf. auch Änderungsaufwand an bestehendem Mapping. Daher glaube ich nicht, dass es von heute auf morgen passiert. Aber man sollte sich Gedanken darüber machen, und das am besten im globalen Rahmen – ist ein bisschen nervig, aber so ist es nun mal.

Offline

#25 2017-10-29 12:52:44

lukie80
Member
From: Rhein-Main-Gebiet
Registered: 2017-04-25
Posts: 18

Re: Straßen (auch) als Flächen mappen...

Kleiner Einwurf meinerseits: Aktuell werden Straßen ihrem Typ nach mit einer zoomabhängigen normierten Breite gezeichnet. Ich denke, dass das zunächst sinnvoll ist als Abstraktion, um ein einfaches Ablesen der Karte zu ermöglichen. Im Prinzip machen das alle gedruckten Karten so.  Das Problem ist dann wohl hier, dass Abstraktion (Lesbarkeit / Nützlichkeit) und Realität (Sattelitbild / Micromapping) aufeinander treffen, wobei ich die gut ablesbare Abstraktion als höherwertig ansehe als die Reale Straßenbreite. Hierbei spielen für mich die "Lücken" eine Vermittlerrolle zwischen Abstraktion und Realität, was an sich gut ist. Man kann die Lücken/Flächen vielleicht als  landuse=highway taggen und das Seitengrün als landuse=meadow/rock/... und die abstrakte Straße dann on-top.

Ich denke die reale Straßenbreite zu rendern ist kein guter Weg, denke ich (zumindest nicht in DE). Das könnte zu Verwechslungen zwischen den Klassen (primary, secondary, ...) führen, nur weil eine Gemeinde mehr oder weniger Geld für Asphalt hatte.

Als Zwischenlösung, die sowohl der Abstraktion als auch der Realität dient, könnte man die Anzahl der lanes auswerten und programmatisch die gerenderte Breite normiert anpassen. Das dürfte die Übersicht nicht gefährden.


Mein vor-Ort-mapping Gebiet via hdyc.

Offline

Board footer

Powered by FluxBB