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 :wink: 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… :slight_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 :wink: 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 :slight_smile: - 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… :slight_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 :wink:

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:

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:

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 :slight_smile:

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

–ks

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.

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

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.

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.

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.

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.

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.

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 :slight_smile:

http://www.openstreetmap.org/edit#map=20/49.51156/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 :wink:

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

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.

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:

Zu jetzt, nachher:

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.

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.

Etwas OT:

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_eyes:

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.

… 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

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

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

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

–ks

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=falkOriginal&gp=49.511863,8.557190&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) :slight_smile: 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? :slight_smile: ) als Fläche. Die Flussmitten jedoch haben ihre Polyline… wie z.B. hier beim Rhein http://www.openstreetmap.org/way/83015625#map=9/51.3436/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

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.

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.