Mangels einheitlicher Regelung eben so, wie es dem Chefentwickler logisch erschien: width als Gesamtbreite inklusive Gehsteige.
Die sidewalk:right:width (o.ä.) werden noch gar nicht ausgewertet, ebensowenig die Lane-Wertlisten. Das liegt daran, dass ich aus Zeitgründen noch nicht zum Einbau gekommen bin. Die technischen Voraussetzungen wären gegeben.
Nun ja einige Highway-Typen sind eher unkritisch, da man dort erst mal keinen zusätzlichen Gehweg vermutet:
Andere Straßen sind eher unklar:
Die gleichen Überlegungen gelten natürlich auch für Radwege und kombinierte Rad-/Fußwege.
Als Auswerter würde ich entweder alle width-Tagg an highway=* ignorieren oder nur beim ersten Block berücksichtigen. Beim zweiten Block höchstens als Fahrbahnbreite betrachten, was natürlich falsch sein kann und würde es daher unterlassen.
Da weiß ich auch keine Antwort.
Ich möchte jedoch sagen, dass die Einigung auf eine Tagging-Variante für Fahrspuren schon ein großer Fortschritt ist.
Das Lane-Proposal bezieht sich nur auf Fahrbahnen und den Fahrspuren darauf. Selbst die Stand- und Parkstreifen sind nicht enthalten. Das mag man bedauern, ist im Sinne der Einfachheit/Übersichtlichkeit aber nachvollziehbar.
Um den gesamten Straßenraum einschließlich der Stand-/Parkstreifen, Fuß-/Radwege und entsprechender Trennungen (soweit vorhanden) bräuchte es ein neues Schema. Dass kann dann die Fahrbahn mit ihren Fahrspuren als eine Einheit behandeln, da Verfeinerungen bereits durch :lanes= abgedeckt sind.
Edbert (EvanE)
Gibt es schon Neuigkeiten bei diesem Thema? Würde ganz gerne mal die Straßenbreiten erfassen, bin mir aber wegen Parkplätzen am Straßenrand nicht sicher was gemessen werden soll. Gehsteige finde ich mit sidewalk:width*=* sinnvoll und width=* für die Straße selbst.
Und um das Thema noch zusätzlich zu verkomplizieren: Spurbreite zusätzlich abmessen? Abbiegespuren zu Einfahrten sind oft kleiner als solche vor Kreuzungen.
Noch etwas: Was wäre eine sinnvolle Angabe für eine Wendeplatz? Durchmesser oder Radius?
Die spinnen, die Römer.
Nach allem, was ich getestet habe, ist die Erfassung der Straße als Fläche ein Mittel der Wahl.
Sonst gibt es zu viele Ausnahmen und Diskussionspunkte über die wir eine Ewigkeit weiter reden werden ohne sinnvolle Ergebnisse zu bekommen.
Wieso sollen wir auf den alten Ansatz pochen, der aus der Zeit ohne Luftbilder stammt, wenn wir mittlerweile sehr gut die Straßengeometrie abbilden können?
Weil die Daten aus OSM nicht nur zur Erstellung schön aussehender Karten verwendet, sondern auch für Navigationsanwendungen benötigt werden? Stand der Technik ist bei allen Anbietern/Geräten “Routing auf Linien”. Für bleibendes/wachsendes Interesse an OSM als Datenlieferant sollte sich das Projekt an die technischen Konventionen halten.
Grüße
Mario
Routing ist nicht gerade mein Spezialgebiet, aber könnte man nicht beides machen? Die Straßen nach und nach als Flächen erfassen und dennoch eine generalisierte Linie im Zentrum? Die “alten” Router können weiterhin arbeiten und moderne schaffen das auch mit den Flächen?
Nur so eine Idee.
Gruss
walter
Ach ja: bei den breiten Flüssen gibt es auch sowas: Waterway und Riverbank - zumindest an vielen Stellen (Rhein)
Lieber Mario,
hat damit nichts zu tun.
OSM bildet die Realität ab. Routing soll natürlich so bleiben wie es ist und die Polylinie mit highway=* und lanes=* ist die Grundlage dafür. Die Flächen sind ja ählich zu vertehen, wie bei dem breiten Fluß: Wir zeichnen ja die Mittelachse und an der die Flußrichtung.
Ohne dass wir die tatsächliche Ausprägung der Wasserfläche wäre die Karte natürlich für einige Zwecke weiterhin gut verwendbar.
Trotzdem ist es mittlerweile Standard weil die Karte besser aussieht und auch mehr bietet.
Wie könnte eine solche Karte mit Straßen aussehen?
Hier ein Beispiel:
http://www.openstreetmap.org/#map=18/50.03065/22.03795
Ich sitze im übrigen gerade an dem Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
Am Wochenende sollte ich damit fertig sein. Momentan ist es a little bit cryptic 
Lieber Walter,
das geht durchaus! mittlerweile ist es Standard und in vielen Situationen würde dies für uns die Arbeit vereinfachen;
Etwa bei unregelmässigen Flächen wo man eigentlich überall rumfahren darf.
Dem stimme ich zu. Das läuft auf ein landuse/landcover=street/highway hinaus, was ja hier auch schon angesprochen wurde.
Mit den Straßenlinen beißt sich das ja nicht zwingend. Nachteil ist allerdings, dass dadurch Redundanzen entstehen (Name an Fläche und Linie).
Auch da geht die Entwicklung weiter: Durch die genaueren Vorlagen werden vielfach auch schon bei kleineren Flüssen die Flächen gemappt (riverbank ist dafür ein etwas irreführender Begriff).
Etwas inkonsequent ist es schon, wenn zum einen zig Meter breite Plätze nur durch einen Strich erfasst werden, woanders aber zwei Meter Gestrüpp eine Fläche (natural=scrub) ergeben.
Für die Straßen als Flächen bräuchten wir halt keine Namen.
Die Visualisierung dieser Idee fand ich schon recht beeindruckend:
http://www.openstreetmap.org/#map=18/50.03029/22.03670
Ich bin mehr für highway=killefitt - aber als geschlossenes Polygon. Keine neuen Keys/Tags sondern einfach nur die Geometrie. Geht in Richtung Area.
Dafür landuse und Co zu verwenden, behagt mir garnicht.
Gruss
walter
Ich bin ebefalls gegen landuse.
Was bedeutet killefitt?
Ich nehme an, dass er meint, dass die Fläche zu einem highway=secondary auch ein highway=secondary ist
Sorry, ist so ein deutscher Begriff für “alles mögliche”. oder auch Schnickschnack.
Gruss
walter
Ich glaube, wir sind uns in der Sache einig, wir suchen nur nach einem Taggingschema?
Oder?
nö, nur “anders zeichnen” - ist zumindest meine Meinung. Das müsste wirklich ohne andere oder gar neue Tags gehen.
highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.
In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?
Gruss
walter
Lieber Walter,
nun, mal wollen wir eine Donut Topologie, Mal nicht. Also Linestring bzw.geschlossener Linestring. Vielleicht verstehe ich hier aber Was nicht.
Es wäre schön, wenn Du anhand eine Skizze zeigen könntes wie Du es meinst.
Grüße,
Marek
Ich glaube auch, dass er vergessen hat, dass ein highway eine geschlossene Linie nicht als Area interpretieren darf, da sonst seeeeehr viel kaputt geht.
Ganz einfach:
Ein Way im OSM-Sinn ist eine einfache Linie aus mehrere Punkten. Das nennt man in GIS: Linestring. — Eine Fläche ist ein geschlossener Way und das nennt man “Closed Linestring”.
Straßen bestehe bei uns aus mehreren Ways - die landen automatisch in planet_osm_roads. Aber auch Mauern oder Hecken oder Richtfunkstrecken: alles sind Linestrings. Der Tabellenname …roads ist nur historisch.
Sobald der Way geschlossen ist (erster und letzter Node sind identisch) wird das ein “closed linestring” und landet in planet_osm_polygon. Das ist zum Beispiel bei allen Landuse (residential, commercial, …) oder highway=service der Fall - völlig unabhängig vom Tagging.
Danach hat man als Auswerter die freie Auswahl: nehme ich die Straßen aus der Roads-Tabelle oder aus der Polygon-Tabelle oder gar aus beiden. Mapnik nimmt auf jeden Fall beide.
Multipolygone/Boundaries werden ähnlich behandelt: Routen landen bei den Roads und Flächen bei den Polygonen. Ebenfalls vollautomatisch.
Was ich eigentlich klarstellen möchte: Ein spezielles Tagging um Wege von Flächen zu unterscheiden, ist mMn nicht nötig. Das macht die Software mit links - und zwar seit 2007 (?)
Gruss
walter
EDIT: Nun, ich hab das ein wenig generalisiert, aber das Prinzip sollte schon zu erkennen sein.