Weg mit unterschiedlichen Oberflächen pro Fahrspur - wie taggen?

Hallo zusammen,

es geht um diesen Weg: https://www.openstreetmap.org/way/26840360

Dieser Weg sieht so aus:

Es scheint so, als wenn der Feldsteinpflaster-Weg links verbreitert wurde. Nördlich endet dieses Teilstück vor einer Brücke und ist dann für wenige Meter vollständig surface=cobblestone.

Aktuell ist der Weg nur mit tracktype=grade4 getaggt. Das würde ich auf grade2 ändern. Aber surface? Und smoothness?

Edit: track_type → tracktype

Ich glaube das ist nicht möglich.

Im Prinzip ist es ja: compacted für Zweiräder, natural_cobblestone für Vierräder. Vielleicht kann man das abbilden indem man einen cycleway=street, cycleway:surface=compacted zu surface=natural_cobblestone hinzufügt.

Mit :lanes arbeiten. Hab ich bei https://www.openstreetmap.org/way/531534492 mal gnadenlos durchgezogen, da ist links Verbundsteinpflaster.

–ks

Ich würde in dem Fall “das Schlimmste” eintragen. Also cobblestone und die dazugehörige Oberflächenglätte.

Danke für Eure Ideen und Vorschläge.

Ich hatte noch an surface=cobblestone;compacted gedacht. Aber der Vorschlag von kreuzschnabel (lanes) finde ich gut. Wird sogar als passendes Beispiel im en-Wiki genannt:

Mit lanes habe ich noch nicht großartig gearbeitet, aber es gibt ja sogar die Möglichkeit mit default-Werten zu arbeiten (für Router, die lanes nicht auswerten):

surface=cobblestone
surface:lanes=|compacted 

Den Wert kenne ich gar nicht. Konnte ich bei taginfo auch nicht finden.

Finde ich passend für Wege ab highway=service aufwärts, bei denen es mehrere Fahrstreifen für zweispurige Fahrzeuge gibt (dort wo also auch lanes=n angeben ist).

Wenn der Belag für die kleineren Wege (hw=track oder hw=path) unterschiedlich ist, habe ich surface:left und surface:right gefunden, Beispiel:
https://www.openstreetmap.org/way/225310903

Was haltet ihr davon?

Ist auf jeden Fall zutreffender als ein lanes-Tagging. Da werden aus dem track zwei parallele Fahrrad-lanes, die der Traktor jeweils mit zwei Rädern benutzt :roll_eyes:.
Das sind eben keine zwei getrennten Fahrstreifen für eine Fahrzeugart, auch wenn ich mit dem Fahrrad nur eine der Spuren nutzen kann. Der deutsche (und englische) Sprachgebrauch sind da leider etwas mehrdeutiger als die StVO.

Übrigens: grade2 ist das auf den unteren Bildern mMn nicht.

Ich hatte jetzt den Vorschlag von kreuzschnabel bereits übernommen, aber die Kritik bezüglich lanes kann ich nachvollziehen. Könnte man mit surface:mid auch für die manchmal vorhandene “Radspur” in der Mitte von Feldwegen verwenden. Mir ist auch ein Thema noch im Hinterkopf, wo es um differenzierte surface-Angaben für ein-, zwei- oder dreispurige Fahrzeugarten ging.

Bin für Verbesserungsvorschläge offen! :slight_smile: Ich habe noch so meine Probleme mit der richtigen Zuordnung von tracktype, smoothness und co.

Hatte heute auch mal wieder sowas. In der Mitte Kopfsteinpflaster, an beiden Rändern Asphaltstreifchen, die auch noch unterschiedlich breit sind.
https://imgur.com/OiIisvh

Gibt es mittlerweile einen Konsens, wie sowas getaggt wird?

Meiner Meinung nach bräuchten wir Oberflächentags nach Fahrzeugart. Dann ließe sich die bestmögliche Oberfläche nach Fahrzeugart taggen. Für PKWs und mehrspurige Fahrräder (bspw. breite Kinderanhänger) wäre das hier “unhewn_cobblestone”, für einspurige Fahrräder “asphalt”.

In der Situation auf dem Foto kann man mMn mit cycleway arbeiten. Hab ich in einem vergleichbaren Fall mal so gelöst: https://www.openstreetmap.org/way/454347939
(Fotos auf Mapillary)

Im allgemeinen stimme ich dir zu: surface und smoothness können für ein- und zweispurige Fahrzeuge dramatisch unterschiedlich sein. Da sehe ich im Moment kein gutes Taggingschema für.

Geht diese Beispiel nicht mit :lanes oder ist die “shared_lane” keine Spur?

surface:lanes:backward=sett|paving_stones
surface:lanes:forward=sett|paving_stones
smoothness:lanes:backward=bad|good
smoothness:lanes:forward=bad|good
width:lanes:backward=|
width:lanes:forward=|

Vielleicht ja vom :lanes-Tagging klauen:

surface=mixed_lanes
surface:mixed_lanes=asphalt|unhewn_cobblestone|asphalt
width:mixed_lanes=0.5|3|1
smoothness:mixed:lanes=good|bad|good

Einziges Problem ist das die Werte beim Ändern der Richtung entsprechend angepasst werden müssen. Also doch:

surface=mixed_lanes
surface:mixed_lanes:backward=unhewn_cobblestone|asphalt
surface:mixed_lanes:forward=unhewn_cobblestone|asphalt
width:mixed_lanes:backward=1.5|0.5
width:mixed_lanes:forward=1.5|1
smoothness:mixed:lanes:backward=bad|good
smoothness:mixed:lanes:forward=bad|good

Das geht halt nicht bei Fahrrad- und Fußwegen, aber da funktioniert i.A. cycleway:* und footway:*.

Konsens ist immer schwierig in OSM.

Aber ich hätte das tatsächlich drei lanes getaggt und die jeweilige Breite und Oberfläche der Fahrspuren mit angegeben.

Ein cycleway=lane oder cycleway=shared_lane ist das m. E. nicht, es sei denn, es gibt irgendwo Schilder, Symbole oder Fahrbahnmarkierungen, die eines von beiden nahe legen.

Ich denke nicht, dass wir Fahrzeugtyp-abhängige Attribute benötigen. Das ist zu viel Interpretation und zu unflexibel. Wir sollten einfach das beschreiben, was wir vor Ort vorfinden und die Interpretation dessen Routern überlassen. Hier wäre das also die unterschiedlichen Oberflächen-Arten und deren Breiten beschreiben.

evtl. mit surface als Namensraum?

surface:right/mid/left=*
surface:right/mid/left:smotthness=*
surface:right/mid/left:width=*

Zu surface: unhewn_cobblestone ist das nicht, da die Oberflächen bearbeitet und (relativ) eben sind. unhew_cobblestone sind runde Feldsteine, wie man sie z.B. auf alten Hofeinfahrten vorfindet.

surface:lanes, width:lanes und smoothness:lanes gehen wohl tatsächlich, siehe https://wiki.openstreetmap.org/wiki/DE:Fahrspuren. Ich dachte, das ginge nur für “volle” Spuren (breit genug für zweirädrige Fahrzeuge) (so wie lanes=*, was verwirrend ähnlich klingt), das ist aber nicht so. Etwas unschön ist, dass die mittlere “Spur” für beide Richtungen gilt, und dass zweirädrige Fahrzeuge in der Praxis mit einer Seite auf der Asphalt-“Spur” fahren werden. Aber vielleicht ist das nicht so schlimm.

cycleway=lane wäre natürlich falsch hier, damit bin ich einverstanden, das müsste explizit markiert sein, je nach Land und geltendem Recht. shared_lane finde ich vertretbar, dafür hängt die Latte viel niedriger; shared_lanes haben keinen rechtlichen Status. Die müssen nur irgendwie “markiert” sein; unterschiedliches Material könnte reichen. Ich unterstelle dabei dem Straßenbetreiber, das Kopfsteinpflaster gezielt für Zweiradfahrer entschärft zu haben. Bei einigen Straßen in meiner Nähe weiß ich das sicher, die Planungsunterlagen hab ich gelesen. Die Situation auf dem Foto kenne ich nicht gut, da ist meine Interpretation natürlich angreifbarer. Es könnte natürlich auch sein, dass die Straße erst nur schmales Kopfsteinpflaster hatte und dann verbreitert wurde, und zufällig war Asphalt der Belag der Wahl dafür. Damit wäre meine Argumentation u.U. hinfällig.

+1. Für mich wäre das sett (mit ziemlich grottiger smoothness, so wie das aussieht)

Vorsicht: Sind das wirklich eigene Fahrspuren? :forward/:backward sind immer richtungsbezogen und :both_ways ist hier schwierig. Ist das nun eine Spur oder zwei in der Mitte? :lanes:both_ways geht auch nur mit spiegelsymmetrisch angeordneten Werten ansonsten sind wir bei :lanes:both_ways:[backward|forward]

Sehe ich problematisch, den Streifen Asphalt hier als share_lane einzustufen. Machst Du das auch wenn der Streifen in der Mitte liegt, oder der Belag genau umgekehrt verteilt ist? Der unterschiedliche Belag allein kann mM nicht das Kriterium sein. Irgendeinen Hinweis zum Bezug Fahrrad braucht es da schon.

+1

left/right ist hier schwierig. Habe schon mehr als drei Streifen mit unterschiedlichem Belag vorgefunden. Was dann? Daher ja mein Versuch mit mix_lanes weiter oben.

unhewn_cobblestone ist falsch. Aber sett hat die Situation auch nur verlagert und Konfliktpotential mit paving_stones. Für mich ist das Kopfsteinpflaster und es gibt einen großen Unterschied zu geschliffenen oder “gebackenen” Steinen. Zusätzlich sind hier die Fugen ausgefüllt was einen großen Unterschied macht zu den Fugen in denen eine schmaler Vorderreifen vielleicht plötzlich feststeckt.

Ich halte suface:lanes für vollkommen untauglich für die Darstellung der unterschiedlichen Straßenbeläge aus Beispiel https://imgur.com/OiIisvh
Mit lanes sind markierte Fahrspuren gemeint. Mit surface:lanes würde man in diesem Beispiel eine dreispurige Straße vorgaukeln, die das definitiv nicht ist. Ich halte daher surface:lanes nur geeignet, wenn es sich um komplette Fahrspuren handelt.

Andererseits zeigt das Fotobeispiel auch, dass es sich um eine gerade für Radfahrer wichtige Information handelt. Es macht halt einen großen Unterschied, ob es einen durchgängigen schmalen Asphaltstreifen gibt oder die Straße komplett eine Kopfsteinpflasteroberfläche besitzt.

Für unterschiedliche Oberflächen innerhalb einer Fahrspur, wie dies bei einspurigen Feldwegen vorkommt, halte ich surface:right/left/middle für geeigneter. Auch bei dem Beispiel https://imgur.com/OiIisvh halte ich es für passender, obwohl man die Straße trotz fehlender Fahrbahnmarkierung aufgrund ihrer Breite vielleicht sogar als zweispurige Straße bezeichnen könnte. Aber sie ist halt höchstens zwei- aber gan bestimmt nicht dreispurig. Außerdem hat der Asphalstreifen nicht die Breite einer kompletten Fahrspur. Mit einem zweispurigen Fahrzeug ist man dort immer mindestens mit den linken Rädern auf Kopfsteinpflaster unterwegs. Ich halte es auch für eine Überinterpretaiton, bei dem Asphaltstreifen handele es sich um Radfahrspuren. Dazu bräuchte es eine entsprechende Fahrbahnmarkierung. Aus meiner Sicht ist das einfach eine zunächst gepflasterte Straße, bei der Begegnungsverkehr früher auf die unbefestigte Bankette ausweichen musste, bis man rechts und links die befestigte Fahrbahn durch einen Asphaltstreifen verbreitert hat.

Sehe ich auch so. Wird auch schon ca. 1.500 mal verwendet (hauptsächlich surface:middle).

Nur wie können wir width und smoothness getrennt angeben? smoothness könnte man auch noch mit smoothness:right/left/middle angeben (8 mal vorhanden). Aber width? surface:right/left/middle:width=* ?

Ich habe leider hier schlecht zitiert. Meine Frage nach :lanes-Tagging bezog sich auf https://www.openstreetmap.org/way/454347939 nicht auf das ursprüngliche Beispiel. Zu letzterem habe ich in #15 schon alles gesagt.
Allerdings sei bitte vorsichtig was die Interpretation von “kompletten” Fahrspuren angeht. Das können durchaus schmalere Streifen wie Fahrradstreifen sein.

Ist ja alles gut, aber was mache ich bei mehr als drei verschiedenen Streifen? Ich finde das zu wenig flexible und würde mich über eine komplettere Lösung freuen. Dann auch mit der Möglichkeit die einzelnen Breiten einzutragen.

BTW: Werden dann surface=* und smoothness=* gar nicht gesetzt oder was wird als Wert verwendet?

Vorsicht: Das dachte ich auch, wurde hier bzw. im englischen Forum eines Besseren belehrt:

Fahrspuren haben in der Mehrzahl der Länder keinen Markierungen. Die bei uns in Städten häufiger anzutreffende “Überbreite Fahrspur”, in der 2Kfz nebeneinander fahren können, nicht aber Kfz und LKW, hat auch keine Fahrbahnmarkierungen, soll aber als 2 Spuren getaggt werden.

Das bei einer lane von “normalbreiten” zweispurigen Fahrzeugen auszugehen ist, trifft auch nur solange zu, wie für die einzelnen Lanes keine Breiten angegeben werden. Aus Sicht eines Radfahrers hat ein Feldweg 2 bis 3 Spuren.

Aber ich stimme dir zu, dass das ‘lanes = 3’ an z. B. einem Feldweg sehr skuril wirkt und Steilvorlage für fehlerhafte Dateninterpretation ist. Nicht jede Maschine wird die Breitenangaben der einzelnen lanes durchgehen um zu entscheiden, dass der Feldweg mit drei Spuren nur eine Kfz-Spur hat.

Skurril ist das, keine Frage. Aber die Realität OTG ist auch skurril und kommt so nicht oft vor (in den Weltgegenden, in denen ich mich herumtreibe). Passt also.
Persönlich bin ich da leidenschaftslos.
:lanes hat den Vorteil, dass wir die Situation mit etablierten Tags abbilden können. Nicht alle Datennutzer werden damit umgehen können, dann muss denen halt auf die Finger geklopft werden.
Ansonsten müsste ein neues Taggingschema kommen. Die Idee mit den mixed lanes finde ich, z.B., nicht schlecht. Macht halt Arbeit. Und bis Datennutzer damit umgehen können, dauert es noch länger. Falls das je klappt.