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