Danke - das klingt gut und liest sich definitiv besser und ist zumindest für mich verständlicher. Vielleicht gibt’s dazu von anderen Mitgliedern noch weitere Kommentare, dies würde mich interessieren.
Wir sollten allerdings die Bemerkung über die Umfrage weiter unten auf der Wikiseite nicht unter den Tisch fallen lassen, die mindestens eine rechtliche Trennung der Fahrtrichtungen verlangt (kein Überholen im Gegenverkehr).
–ks
Oh, soweit herunter bis zur Umfrageerwähnung hatte ich gar nicht gelesen. (Schade, dass die Quelle nicht mehr angezeigt wird) Ich habe mal in die Änderungsgeschichte [1] der wiki-Seite geschaut und wenigstens noch diesen [2] funktionierenden Link zu einem anderen Forum-Thread gefunden, wo die Ergebnisse von damals etwas detaillierter in einer Übersicht gelistet sind. Vielleicht könnte man den toten Link (der zur Umfrageseite zeigt) durch den Forum-Thread-Link [2] ersetzen.
[1] https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:highway%3Dtrunk&diff=prev&oldid=1236853
[2] https://forum.openstreetmap.org/viewtopic.php?id=52550
Ja, ich bin dafür die Info’ drin zu lassen, weil sie auch in die Richtung geht, die ich ein Stück weit teilte. (hw=trunk’s für Strecken mit fehlender Überholmöglichkeit nicht zu verwenden).
Nebenbei, der Umfrageerwähnungstext enthält aber auch wieder eine kleine formulierte Unverständlichkeit:
Aktuell:
„Eine Mehrheit der Teilnehmer einer Umfrage sprach sich für weitere Kriterien für trunk in Deutschland aus, ohne dass eine der
Verschärfungsoptionen allein eine Mehrheit hatte. …“
Meine Vorschlag (gerne wieder ausbaubar) für Änderung:
„Eine Mehrheit der Teilnehmer einer Umfrage sprach sich für weitere Kriterien aus, die die Definition von hw=trunk in Deutschland
enger fasst, ohne dass eine der Verschärfungsoptionen allein eine Mehrheit hatte. …“
Das könnte man dann ggf. im selben Zuge (im selben wiki-Änderungssatz) anpassen.
Also mein Standpunkt zu den beiden „weichen“ Kriterien
i) fehlende bauliche Trennung und
ii) fehlende Überholmöglichkeit / nur eine Fahrspur pro Fahrtrichtung (1+1 oder 1+2 oder 2+1)
sieht so aus:
i Eine generell fehlende bauliche Trennung spielt für mich keine Rolle (ist für mich kein Kriterium => ist demzufolge auch für‘s Beispiel, ob man für B27 hw=trunk oder hw=primary nimmt nicht relevant)
ii Streckenabschnitte mit nur einer Fahrspur pro Fahrtrichtung (fehlender Überholmöglichkeit) interessiert mich mehr und ich bin für diese Fälle grundsätzlich eher geneigt hw=primary zu verwenden (also gegen hw=trunk). Deswegen, weil natürlich im Vergleich (V1) zu den Streckenabschnitten mit mehreren Fahrstreifen pro Richtung, bei ersteren eine deutlich geringere Durchschnittsgeschwindigkeit zu erwarten ist. Denn gerade bei diesen Stecken (häufig Kraftfahrstraßen) an denen hw=trunk generell in Frage kommt, herrscht dann oft zusätzlich ein totales Überholverbot wegen vorhandener durchgezogene Mittellinie/Doppellinie. D.h. es gibt hier den Nachteil bei Verwendung von hw=trunk an Strecken mit fehlender Überholmöglichkeit, dass die Router dann zu wenig Zeit für diese Strecken einplanen. Die schlaueren Router könnten aber für diese Fälle sogar die Angabe der Fahrspuranzahl mit auswerten und in ihre Navi-Zeitberechnung einfließen lassen, d.h. dieser Fehler/Nachteil ist mehr oder weniger leicht auf Routerseite behebbar.
Anderseits, wenn man aus der Sicht von hw=primary ausgeht und die Anwendung von hw=primary vergleicht (V2) z.B. an einer „normalen“ Bundesstraße mit Kreuzungen (+Ampeln usw.) oder an einer kreuzungsfreien/anbaufreien Straße (die anhaltefreies Fahren gestattet), erzielt man natürlich an Letzterer Konstellation als Fahrer einen Zeitvorteil / höhere Durchschnittsgeschwindigkeit gegenüber der Zeit die der Router berechnet. Mir fällt für den Moment keine schnelle Lösung ein, wie ein Router diesen „Fehler“ abstellen könnte. Wenn man bei diesem Fall für kreuzungsfreien/anbaufreien Straßen (unabhängigen von der Spuranzahl pro Richtung) hw=trunk verwendet, passt es für mein Gefühl deutlich besser mit der Routing-Zeitplanung.
Weil ich im zweiten Vergleich (V2) den Vorteil höher einschätze als den (auf Routerseite optimier-/reparierbaren) Nachteil im ersten Vergleich (V1), bleibe ich dabei und tendiere im Beispiel B27 weiterhin zu hw=trunk.
Auch generell würde ich für diese Fälle hw=trunk benutzen, so wie es eigentlich jetzt bereits im wiki steht. Aber ich würde mich auch freuen, wenn die wiki-Seite die Kriterien zur hw=trunk Klassifizierung etwas einfacher/strukturierter durch Deinen wiki-Änderungsvorschlag anzeigt und diese wiki-Seitenänderung so eingetragen wird.