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.

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.

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

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.

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

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.

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.