Richtungsabhängiges surface

Hallo,
wie trägt man richtungsabhängige surface korrekt ein?

z.B. Dorfstraßen, die einseitig asphaltiert wurden, auf der anderen noch das alte Kopfsteinpflaster liegt.

Zusatzfrage:
wie trägt man surface ein, wenn nur der Randstreifen asphaltiert wurde oder nur die Mitte der Fahrbahn?

Danke

surface:forward/backward=* abhängig von der Way-Richtung wie üblich.

Streifenweise: surface:lanes[:forward]=*.

–ks

Sind zwar wenig in Benutzung aber

  • surface:forward und surface:backward

oder

  • surface:right und surface:left

wären die Kandidaten, tendenziell würde ich letzteres bevorzugen da unabhängig von Links-/Rechtsverkehr.

Danke. Und wenn bei einer Straße nur 50-100cm jeweils links und rechts asphaltiert sind, in der Mitte aber Kopfsteinpflaster? Für Radfahrer sehr ausreichend, um gut voranzukommen.

Eigenschaften von Spuren auf Straßen werden generell mit :forward und :backward angegeben, nicht mit :left und :right. Letzteres gibt es für Dinge am Rand der Straßen wie Gehwege (sidewalk:left=…) oder Parkflächen (parking:lane:left…)

Das wäre dann surface=concrete:lanes (steht im Wiki) bzw. das seltene surface=asphalt:lanes

Danke, auch an mueschel!

Nein, ich beschrieb etwas anderes. Ich meine z.B. sowas hier https://www.verden.de/medien/bilder/spurwechsel_06_02_2018_burgfeld_019_web.jpg

Dort gibt es auch keine ‘lanes’ im OSM-Sinne, sondern einfach jeweils seitlich einen mehr oder minder schmalen Streifen. Das gibt’s auch umgekehrt ("innen asphaltiert, außen Pflaster).

Vielleicht surface=sett;asphalt:lanes…

https://wiki.openstreetmap.org/wiki/Key%3Asurface

Bei turn:lanes destination etc ist die Anordnung der Spuren im Wert hinterlegt und unabhängig davon ob Links- oder Rechtsverkehr (auch bei richtungsabhängige Geschwindigkeitsbegrenzungen und ähnlichem kommt es nicht darauf an).

Bei dem surface:xx Wert ist das nicht so. Da es mehr Linksverkehr als Rechtsverkehr auf der Welt gibt, läuft dein Vorschlag darauf hinaus, dass in DE (mal angenommen wir bewegen uns in Wegzeichnungsrichtung) für den rechten Fahrstreifen den Wert von surface:backward nehmen müssten (in den Gegenden mit Linksverkehr den Wert von surface:forward).

Ähm, nein.
“turn:lanes” und alle anderen :lanes darf es nur bei einem oneway geben, sonst muss :backward:lanes :lanes:backward und :forward:lanes :lanes:forward verwendet werden.

Edit: Natürlich mal wieder die Reihenfolge der Tags vertauscht…

Stimmt ich liege da wohl falsch (wenn man halt das jeweils so mappt, dass es gerade richtig herauskommt).

Nach Wiki kommt der Richtungsbezug zuletzt, also :lanes:backward und :lanes:forward. Aber andersrum wird’s sicher genauso gut ausgeworten, Router werden da einfach nach dem String suchen, egal wo der ist.

–ks

Ok, das wird jetzt etwas pedantisch – aber ist surface:forward wirklich richtig? Ich würde dafür surface:lanes:forward nehmen, auch wenn es nur eine Spur in jede Richtung gibt.

Das forward/backward-Suffix bezeichnet eine von der Fahrtrichtung abhängige Einschränkung, d.h. etwas das sich ändert, wenn man in die andere Richtung fährt.
Das lanes:forward/lanes:backward-Suffix bezeichnet hingegen eine Gruppe von Spuren – d.h. denjenigen Teil der Straßenoberfläche, der fürs Fahren in eine bestimmte Richtung genutzt wird.

Vielleicht zur Illustration: Ein maxspeed:forward/backward könnte es theoretisch sogar auf einer einspurigen Straße geben, denn es geht ja nicht um einen Teil der Fahrbahnoberfläche, sondern um die Bewegungsrichtung des Verkehrsteilnehmers.

Das Bild für surface:forward vor meinem inneren Auge ist also eine Straße, deren Oberfläche sich magisch in Asphalt verwandelt, wenn man wendet. :wink:

Jetzt könnte man natürlich sagen: Das gibt es in der Realität ja nicht, also ist ja klar was gemeint ist. Aber aus Auswertersicht ist das nur dann sinnvoll, wenn z.B. auch ein maxspeed:forward=80 und maxspeed:lanes:forward=80|80|80 in allen Fällen gleichbedeutend sind.

Und da bin ich mir jetzt nicht sicher: Ist das so? Wenn das auch international allgemeiner Konsens ist, sollte es wohl dokumentiert werden.

Da ist leider die Lage der Oberflächenstreifen zueinander nicht klar. Ich würde eher surface + surface:middle erwägen. Wobei natürlich auch das Unterscheidung zwischen klassischen “lanes” (also befestigter Oberfläche dort, wo die Räder eines Autos wären) und dem hier vorliegenden Fall nicht leisten kann.

Das sehe ich ganz anders und halte umgekehrt das Aufweichen von “lanes” für einen grundsätzlichen Fehler. “lanes” sind für mich abmarkierte Spuren. Wenn eine Wohnstraße 5 m breit ist (Parkstreifen außen vorgelassen) und sich also zwei Autos hier i.d.R. begegnen können, sind das für mich keine lanes=2. Das kann mit width=5 viel besser dargestellt werden. Denn zwei LKW kämen hier z.B. nicht aneinander vorbei und das ganze lanes-Ding würde einfach eine große Sache der Interpretation (der eine hält Grenzfälle eben schon für lanes=2 der andere noch nicht). Kommen wir zurück: Wenn Du hier “surface:lanes:forward” einführst, implizierst Du ja etwaige lanes. Und das heiße ich nicht gut.

Wieso? Es geht doch genau um die Richtung des OSM-ways, nicht um die Fahrtrichtung?! Steh’ ich jetzt auf’m Schlauch, oder Du?! :wink:

“middle” halte ich für zu/sehr schwammig. Wie breit ist “middle” im Konkreten? Das kann ja von einer schmalen Gosse aus anderem Material in einer mittelalterlichen Straßenmitte bis zu einem etliche Meter breiten mittigen Belag mit nur schmalen Randstreifen mit anderer Oberfläche reichen.

Wir brauchen da was Geeigneteres! Im Moment halte ich die forward/backward-Lösung noch für das beste. Oder müssen wir darauf warten, bis highways als Flächen getaggt werden? :smiley:

Jaja… beim Tippen vertauscht. Ich wäre mir da nicht so sicher, dass die andere Reihenfolge auch gefunden wird.

Die Zusammenfassung für die übliche Reihenfolge ist übrigens:

key[:subkey][:hgv|:bicycle|...][:lanes][:forward|:backward|:both_ways][:conditional][:start|:end]=*

Wenn es nur eine Spur gibt, dann sind beide Tags identisch. Ich würde aber dazu tendieren das “:lanes” dann wegzulassen. Niemand hindert einen ja daran, das “:lanes” Suffix zu verwenden und dann eben nur eine Spur anzugeben.
2 Spuren zu “erfinden”, wo keine sind, das ist natürlich falsch.

surface:bicycle=asphalt d&r :sunglasses:

Du bist jedenfalls nicht der Geisterfahrer. :wink:
Ich versteh auch nicht, wieso die plötzlich auf die Fahrt- oder Bewegungsrichtung kommen!

Ein Schlüssel der Form

key:forward = value

bedeutet, dass für Verkehrsteilnehmer, die sich in Zeichenrichtung des OSM-Ways bewegen, die Eigenschaft

key = value

gilt.

Zumindest für mich besteht da ein subtiler Unterschied gegenüber einer Eigenschaft, die für diejenige Hälfte der Straße gilt, die üblicherweise von den in diese Richtung fahrenden Verkehrsteilnehmern genutzt wird.

Ein way kann doch nicht verschiedene surface haben. Dann sind es jeweils Stücken des ways.

Sollte ein way verschiedene Spuren mit unterschiedlichen surface haben - dann gehört das in lane:forward:surface=* und lane:backward:surface=* - auch wenn bei schmaler Straße mit lane:forward:width=1 und lane:backward:widt=2.5. Dann muss ich forwards mit der linken Fahrzeugseite auf einen anderen surface fahren (und backwards kann ich es - vielleicht).

Auch wenn ein Validator meckert, das nur lanes=1 an einer einspurigen Straße geben kann.

Ich würde für physische Eigenschaften auch eher left, middle, right verwenden, da sie sich wie Gehsteige u. dgl. eben physisch auf die entsprechende Seite beziehen.

Für mich ergibt sich auch ganz magisch, dass sich ein surface:forward bei Rechtsverkehr auf die rechte Fahrspur(en) und bei Linksverkehr auf die linke Fahrspur(en) (in way-Richtung) beziehen müsste.
Und somit bei einer staatlichen Verkehrsrichtungsänderung das Tagging plötzlich falsch wäre.
(Ich verstehe daher auch nicht, wieso sich nach SimonPoole ein surface:forward wegen des weltweit vorherrschenden Linksverkehrs weltweit auf die linke Seite in way-Richtung beziehen sollte …)

Mir ist ebenso klar, dass sich ein *:forward oder auch ein lanes:forward nicht eignet, um einen (Bruch-)Teil einer Fahrspur zu beschreiben.

Daher kam bei mir der Eindruck auf, dass Ihr das forward auf “in Fahrtrichtung” bezogt … statt auf “in way-Richtung”.

Emils “Problemweg” hat weder das eine noch das andere.

Das Einzige, das wir heute nutzen könnten um diesen Weg adäquat zu beschreiben sind Flächen - also area:highway. Weder Spurtagging, noch ein spezieller Wert für “surface” helfen uns da weiter, weil es gerade keine Spuren sind und die Eigenschaft auch nicht von der Fahrtrichtung abhängt.

Ich würde das zur Zeit so erfassen:

surface = cobblestone  (für "sett" scheint es zu uneben) 
surface:left = asphalt 
surface:right = asphalt
surface:bicycle = asphalt