Strassenbreite, sidewalks,..

Moin

Kaum will man was einfaches wie sidewalks taggen, gehts wieder los:
Eine Straße hat 2 sidewalks und eine Breite.
Wenn die sidewalks NICHT als seperate Way eingetragen sind, sondern nur am highway als tag
sidewalk=both dranhängen, wie regelt man das mit der Breite/width tag?
Sprich:
gibt der width Tag die Fahrbahnbreite wieder, ohne sidewalks oder mit sidewalks?
Und wenn mans komplizierter haben möchte:
Wie tagt man dann unterschiedliche Breiten? Linker Sidewalks hat 50cm, rechter 1m?
Ist das was verbreitet oder sollte man den Sidewalk als seperaten Way dann lieber eintragen?

Danke
Amiga4000

Meiner Meinung nach wäre es logisch, die Breite der sidewalks in width mit einzurechnen, wenn sie via Tag als Bestandteil des highway modelliert werden.

Es gibt bei cycleways die einigermaßen verbreitete Lösung cycleway:right:width=*. Diese könnte man analog auch für sidewalks nutzen - obwohl sie dort bislang nicht so häufig vorkommt.

Tja, das ist die Frage. Je nach Wichtigkeit für einen selbst wird man das sehr unterschiedlich beurteilen. Für den Autofahrer z.B. zählt nur die Fahrbahnbreite. Halt, gehören Parkstreifen dann noch dazu? Die sind für einen Autofahrer ja auch wichtig.
Für das Kataster zählt nur die gesamte Breite, die als öffentlicher Raum für Straße, Parkstreifen, Gehweg, Radweg, umgebende Grünstreifen und sonstige Ausstattung (Gräben, Leitplanken, …) reserviert sind.

Da ich davon ausgehen, dass für viele die Antwort auf die Frage nach der Breite einer in OSM eingetragenen Straße genauso unklar ist wie mir, trage ich grundsätzlich keine Breite bei Straßen ein. Die abstrakte Zahl der Fahrspuren muss für mich reichen.

Auswerter haben das gleiche Problem. Sie können keine sinnvolle Annahme darüber stellen, was der jeweilige Eintragende denn nun gemeint haben könnte oder welche Interpretation als ‘normal’ gelten könnte. Die regelmäßigen Anfragen hier und in der Mailingliste zeigen das Dilemma recht deutlich.

Wenn man klar stellen will, was man wirklich meint, sollte man also bei Straßen die Breitenangaben nach width:carriageway, width:left/right/both:parking_lane, width:left/right/both:cycleway, width:left/right/both:sidewalk und nicht zu vergessen width:left/right/both:road_green verwenden.
Dabei kann man über die Reihenfolge von Breite:Seite:Bestandteil oder die Namen für die einzelnen Bestandteile natürlich diskutieren.

Und irgendwie müssten wir auch noch über die Reihenfolge der einzelnen Bestandteile reden, die ist nämlich alles andere als eindeutig. Vielleicht sollte man das schlicht wie bei den Fahrspuren als Liste machen.

Eine einfache Frage, die eine Menge von Folgefragen aufwirft und für die es daher keine einfache Antwort gibt.

Edbert (EvanE)

Ich habe ja nicht mit Wichtigkeit argumentiert, sondern mit “Logik”. :wink: Wenn width die Breite des Objekts ist und die Sidewalks keine eigenen Objekte sondern Teil des Objekts highway sind, dann - so die Überlegung - würde ich sie mit einrechnen.

Aber klar, da kann man sich nicht drauf verlassen und letztlich wären nur explizite Tags richtig eindeutig. Was aber auch wieder nicht die Frage löst, was wir mit den 675.145 width-Tags an highways machen.

Ich hatte ja ursprünglich gehofft, dass man auch die Gehsteige einfach als Spur betrachten und auf diese Weise mit in die Spurwertliste aufnehmen könnte. Aber das hat der Autor des Lane-Proposals wohl anders gesehen. :confused:

Das macht die Sache nicht einfacher. Zumal uns dadurch jetzt auch eine Lösung fehlt, die Ordnung der Nicht-Autospuren anzugeben. Also doch die Gehsteige, Parkstreifen, Radspuren mit in die Spurliste? Oder zwei Listen?

Du siehst, mir fehlen hier ebenfalls die befriedigenden Antworten.

Hey

tordanik, wie wertet das denn osm2world aus?

Amiga4000

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:

  • highway=footway/cycleway und highway=path + *=designated
  • highway=path (ohne *=designated)
  • highway=bridleway
  • highway=track
    In diesen Fällen tagge ich auch manchmal eine Breite.

Andere Straßen sind eher unklar:

  • highway=road (ohne Klassifizierung keine Aussage möglich)
  • highway=service (Gehweg nicht sehr häufig, aber kommt vor)
  • highway=residential (in der Regel mit Gehweg, direkt daneben oder abgesetzt)
  • highway=unclassified/tertiary/secondary/primary (unterschiedlich je nach Stadt/Land)
  • highway=trunk/motorway (Gehweg selten, wenn dann abgesetzt (Grünstreifen/Leitplanke/…))
    Gilt entsprechend auch für highway=*_link.

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

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?