Kleinste Straßen

Da das Tag aktuell eher nicht so verwendet wird, würde ich behaupten, dass es z.M. fraglich ist, ob das, das richtig Tag ist. Denn das Tag wird eher punktuell für kurze Abschnitte verwendet. Ich denke es wäre aber nicht falsch das Tag so zu verwenden. Narrow ist eben immer subjektiv, und die Idee des Tags ist glaub ich eher die engen Stellen, die durch Schilder markiert sind, zu kartieren. Und weniger Straßen die jemand als eng empfindet zu markieren.

Jede Kreisstraße in Schleswig Holstein hat die Breite vom Mangenpass und wird von uns Norddeutschen gerne genommen. Für die Kollegen aus Bayern sind die Kreisstraßen die schmaler als eine Landebahn sind schon ungewohnt schmal. Da wird es niemals Allen passen.

Wenn man die englische Beschreibung liest, ist das definitiv das richtige Tag (+width):

Vermutlich nicht ohne viel Aufwand umzusetzen, aber wäre es auch denkbar bei LongTap auf einen der Button 1 - 6

den Straßentyp in der Karte temporär hervorzuheben? Dann kann man sich in jeder Region ein Bild machen, auf welche Straßen die Vermeidung ( oder eben Nichtverrmeidung ) auswirken würde.

Und für (2) könnte ich Fähren enttarnen :slight_smile:

Wo liest du das denn? https://wiki.openstreetmap.org/wiki/Key:narrow

Grundsätzlich, ich hab nix gegen Narrow, ich meine nur, es wird aktuell so, laut meiner Recherche, nicht eingesetzt.

Ja genau, wäre doch etwas mehr Aufwand, die Idee finde ich aber eigentlich ganz nett :slight_smile:.

Habe es gefunden: Key:lanes - OpenStreetMap Wiki

Danke für das saubere Verlinken und @t00thl355 für den Screenshot.

Der Teil war auch meine Hauptquelle. Narrow eher als schwacher Hinweis, dass Höchstgeschwindigkeit nicht erreicht werden kann.

Zudem ist narrow ein relativer Parameter. Ich fahre Dorfstrasse, aufgrund Bebauung oder Schikane habe ich eine Engstelle.

Ganze Strassen ist schwieriger. Im Vergleich zu anderen Strassen wird es überall Strassen geben, welche im Vergleich enger sind. Am Ende wäre alles mit narrow getaggt. Wie ich Robin verstehe, ist das die Befürchtung.

Daher ohne Breite eben maximal ein Hinweis. Die Gretchenfrage bleibt offen. Welche Parameter werden “heute” vom Algorithmus verwendet? Und wie wirkt sich 1-5 aus. Das kann ja high-level bleiben.

Und können die o.g. Parameter wie Breite Sinn ergeben (zukünftig) auch verwendet zu werden?

Mit dem Wissen kann die Karte verbessert werden. Allerdings würde ich mich unwohl fühlen das für Strassen in Italien zu machen. Ganz ohne Abstimmung mit italienischen Mappern eher nicht. Wenn die aber wissen, dass Router das verwenden, werden die vielleicht eine Auge darauf haben.

Zum Beispiel bemühe ich mich, in “meinem Bereich” Geschwindigkeiten in OSM zu verbessern. Die Motivation habe ich erst, seit ich Kurviger verwende und es schon irgendwie nützlich ist. :wink:

Und wenn es nützlich ist und verwendet wird, dann kommen zwangsläufig die Fragen, nach Erkennbarkeit. Für Geschwindigkeit gibt es heute in Kurviger das Geschwindigkeitsdiagramm, wo fehlendes Mapping sichtbar wird.

Rattenschwanz für Robin. :scream:


Anderer Gedanke. Erfinden wir gerade das Rad neu? Wenn ich statt mit Motorrad mit so einem Riesencamper unterwegs wäre? Kennt sich da jemand aus? Welche Parameter sind relevant?

Ich würde auf “unclassified” und “track” tippen.

Ich denke, die Datenlage ist aktuell nicht wirklich ausreichend um “Avoid narrow roads” in der App so anzubieten, wie es von den User teilweise gewünscht ist.

Aktuell Lösungsansätze:
:one:Sonderregel Italien” (z.B. zusätzlich “tertiary” berücksichtigen) ist mMn langfrisrig keine gute Lösung, weil der Fall “Manghen Pass” damit nicht gelöst wäre und solche Probleme auch in anderen Ländern auftauchen können und dann braucht man Sonderregel Rumänien, Polen, USA (da ist “narrow” auch wieder relativ)…
:two: OSM Datenlage verbessern - erfordert natürlich auch Anpassungen in dem Algorithmus, aber auch relativ viel Arbeit in OSM. Dies bringt kurzfristig keine Verbesserung, würde aber über die Zeit wahrscheinlich erwas besser funktionieren, wenn die verwendeten Tags bekannt sind und von Usern ergänzt werden. (Es ist ähnlich wie bei den legal befahrbaren unbefestigten Strassen - Kurviger will nicht dahin, wenn man aber entsprechende Tags setzt - dann funktioniert es super)
:three: Erwartungshaltung der User anpassen - vllt wäre es nützlich, die User auf die datenbedingte Einschränkungen der “Narrow road avoidance” hinzuweisen. Sobald ein User diese Vermeidung verwendet, könnte man ein “Kärtchen” mit dem Warnhinweis unter dem “i-Button” anzeigen. Auf dem könnte z.B. eine Empfehlung stehen, die Route manuell zu kontrollieren (insb. auf Passstraßen).

Nach welchen Kriterien sucht der AlgoR die Routen aus?

Das Problem bei meinem Beispiel mit Manghen ist, dass die Fahrzeit auf dieser Strecke garantiert nicht stimmt. Wenn man also bei solchen Straßen ohne genaue Geschwindigkeitsangaben nicht 60er Schnitt nimmt, sondern 30kmh - wùrde sich das vermutlich (??) auch auf das Routing auswirken. Es geht bei dieser Strecke bzw bei der von mir vorgegebenen um 1 oder 2 km Streckenunterschied, wo man angeblich übern Manghen schneller sein soll - was aber so nicht stimmt, weil da keinen 60er Schnitt fahren kannst.

Zum Thema: Tags bei Narrow Roads und den möglichen Problemen, wenn alle solche Straßen vermieden werden.
Bei cer Einstellung von diesem Straßentyp sind 5 Vermeodungsstärken. Wenn ich dort also 5 eingebe ( ist entsprechend hohe Vermeidung) dann will ich wenn möglich keine solche Tertiären Straßen fahren auf der jeweiligen Route.

Man kann das dann ja individuell einstellen, wenn man doch solche Sträßchen fahren will. Ich seh da in dem Fall kein Problem, dass man damit einige User unglùcklich machen würde. Die Vermeidung ist ja einstellbar!

Ich wollte mal nachschauen, ob diese Straße als “secondary” korrekt eingestuft ist.

Dafür bin ich auf italienische OSM-Wiki gegangen und die Enstufung scheint korrekt zu sein.
Ich habe aber dort auch diesen Satz gefunden (übersetzt auf Englisch):

“Oft nur einspurig” :exclamation_question_mark:

So eindeutig habe ich es nicht erwartet.
Das würde aber bedeuten, dass man aus der reine Strassenklassifizierung keine Rückschlüsse ziehen kann, ob eine Straße schmal ist oder nicht.

Diese Sp31 fängt supertoll zweispurig an - aber nach ca. 1km ist sie dann durchgehend einspurig.

Hab das jetzt mal grob gerechnet. Es sind ca.36km einspurig.
Bei einer Annahme von 60 Kmh Schnitt, brauchst 36min. Bei 30er Schnitt 72 min. ( das kommt hin, weil da fährst über ne Stunde!)
Wenn sowas bei der Planung berücksichtigt würde, dann braucht man für die Strecke Bozen-Vicenza übern Manghen
3Std 46min (190 km)
Bei der Variante von mir ( mit 2 Sh.Points 192km) gibt Kurviger eine Zeit von 3 h 32min an. Also real schneller.

Gemeint ist wohl eher eine Spur pro Richtung: Tag:highway=secondary - OpenStreetMap Wiki

it is normally a paved road with at least one lane per direction, usually separated by a central line. In areas with worse infrastructure road quality may be far worse.

Könnte mir bitte jemand sagen, warum mich kurviger nach dem SP 12 den kleinen Feldweg, teils geteert teils unbefestigt fahren hat lassen obwohl die Vermeidung von “kleinste und unbefestigte Straßen” auf 5 gesetzt sind? Ein entgegen kommendes Auto oder Traktor wäre hier nicht an mir vorbei gekommen.

Danke
Jochen

Meistens passiert das, weil die verfügbare OSM Daten nicht ausreichend sind, diese Straßen als klein und/oder unbefestigt zu erkennen.

Könntest du etwas genauer sagen, wo die kritischen Stellen sind, dann kann ich die entsprechend in OSM eintragen. Ich habe mir die Satellitbildern zwischen WP11 und WP13 angeschaut, teilweise auch Streetview, konnte aber keine unbefestigte Stellen erkennen.

Ich seh das so, das er den Weg meint, in den gleich nach WP12 abgebogen wird. Sieht auf dem Satelitenbild danach aus

Diese 500m? Die sind laut OSM relativ gut beschrieben, angeblich asphaltiert, mit exzellenten Belag und 3,5m breit.

Sollte da etwas nicht stimmen, dann bitte direkt in OSM ändern oder bescheid geben, wo was geändert werden soll.

Ob die 3,5m Straßenbreite für den Algorithmis als “kleinste Straße” gelten, müsste jemand von den Entwickler beantworten können.