Streetcomplete nicht vorhandene Standspur erfassung für Nebenstrassen?

Ok dann war meine vermuttung ja schon ganz richtig.

Da es ja auch nicht sinnvoll ist die Datenbank aufzublähen wäre es denke ich sinnvoll wenn jemand der sich mit dem Programm auskennt die Macher von Streetcomplete drauf hinweisen könnte das solche fragen den nutzern nur noch gestellt werden für highway=trunk oder highway=motorway.

@Hartmut Holzgraf bei highway=trunk oder highway=motorway find ich das ja auch vollkommen richtig aber nicht bei den Strassen die ich als beispiele genommen habe das sind so wie viele weitere bearbeitungen die ich in overpass sehen kann nur highway=unclassified oder highway=secondary mit 2 spuren 1 für jede richtung. Solche strassen haben nie ein Standstreifen.

Nachricht haben sich überschnitten das von flohoff erst jetzt gelesen.

Das ergibt sinn.

Bis jetzt gibt es in meiner gegend nur fast keine Strasse die die shoulder=no tags haben deswegen war ich verwundert als ich das nun so gesehen habe. Da ich hier jede Strasse kenne weis ich das in meinem umkreis von min. 20km nur auf den Autobahnen Standstreifen sind.

Werde noch weitere meinungen abwarten und mich dann später mal damit befassen alle Strassen in meiner umgebung die ich nach lage vor ort kenne die Tags genau zu überarbeiten. Grade beim Licht fehlt hier noch einiges.

Wie gesagt - Das sehe ich anders.

Deine Erfahrung kann kein router/navigationssoftware abbilden. Es kann sich nur drauf verlassen was getagged ist. Und nur weil bei dir in der Umgebung keine shoulder da sind heisst das nicht das das international überall so ist.

Wir müssen das alles explizit taggen. Da führt einfach kein weg dran vorbei.

Ich halte es für richtig was StreetComplete da macht. Also mal davon ausgehend das highway=path|service|track nicht mit shouldern versorgt wird. Da mache es keinen Sinn.

Flo

:smiley: Hatte den beitrag 4 erst nach dem schreiben gelesen

Ich verstehe wie du das meinst aber der Tag ist nicht einmal in einem Deutschen Wikitext zu den verscheidenen Strassentypen zu finden. Selbst bei Autobahnen gibt es dazu nichts https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dmotorway
Deswegen kann man wohl auch davon ausgehen das der bisher in Deutschland auch nicht wirklich verbreitet oder anerkannt ist.

Als ich grade dann noch ein wenig mit overpass rumprobiert habe kommte ich auch sehen das shoulder bisher meist auch nicht an Autobahnen genutzt wird wo man den ja eigentlich vermuten würde, sondern das der oft nur auf Teilstücken von andren Strassentypen getaggt ist. Nach Stichproben wurden zumindest hier im Norden die meisten mit Streetcomplete angepasst.

Gibt warscheinlich wie so oft mehrere möglichkeiten etwas zu mappen und wen das für dich richtig erscheint jede Strasse mit shoulder=no zu erstellen, Kannst du das natürlich auch machen aber ich werde hier kein massenedit machen und diesen Tag zukünftig lieber gleich ganz ignoriren.

Durch deinen andren Beispielen von Tags die du immer nutzt ist mir aufgefallen das ich noch nie genau geprüft habe wo hier noch keine lit Tags gesetzt sind.
Das werde ich die Tage mal umsetzen danke für´s neue neben Projekt :slight_smile:

Edit:
Meiner ansicht nach wäre dazu die beste Lösung wen der Tag shoulder=no genauso ein Standwertwert wäre wie z.b. Einbahnstrassen die ja auch immer no sind. So ein Standartwert den man später auf yes ändern kann ist da doch eine besser lösung als millionen von strassen fragmenten mit shoulder=no auszustatten.

+1
Dieses “Aber dann kann man erst sehen, ob es erfasst wurde” ist schwachsinnig. Man muss eh immer von “no” ausgehen. Zum Überprüfen eines Sets ist dann ein anderes System zu wählen oder eigenständig eine Datenbank zu pflegen. Das ist nicht aufgabe von OSM selbst. Wenn man Straßen etc als Set machen würde, kann man gleich alles zusammen abfragen.

Also erstmal: Der Maintainer von StreetComplete nutzt dieses Forum nicht, daher muss so etwas wohl oder übel auf GitHub:
https://github.com/streetcomplete/StreetComplete/issues

Ein Router kann außer explizit getaggten Informationen auch einprogrammierte Standards berücksichtigen und wird das mit ziemlicher Sicherheit zumindest für manche Tags tun (zumindest auf ein access=yes oder ein oneway=no wird absolut kein Router warten).

Dass wir keine gute Lösung zum programmübergreifenden Dokumentieren von Standards haben, ist leider ein schon lange bestehendes Problem. Aber deswegen für jede Straße shoulder=no bridge=no tunnel=no etc. zu taggen, finde ich die falsche Lösung. Wir zeichnen ja auch kein building=no auf jeden unbebauten Quadratzentimeter Erde. Ich halte StreetComplete generell für übereifrig beim Setzen von =no, und das ist m.E. ein konzeptionelles Problem (es nutzt diese Tags, um Quests als erledigt zu markieren, was m.E. ein Bisschen ein Missbrauch solcher Tags ist). Nachteile ergeben sich daraus vor allem für Nutzer von Editoren, die ganz klassisch alle gesetzten Tags anzeigen. Dort leidet die Übersichtlichkeit unter dem Tagging von Offensichtlichem.

Nun das klingt für mich ziemlich überheblich. Denn in Gebieten wo ständig jemand drann ist, mag Deine These ja richtig sein. Aber das ist eine Minderheit

Und natürlich ist es ziemlich dumm, nicht zu wissen, ob eine Sachlage nun erfasst oder “erraten” ist. Spätestens wenn du einen längeren unclassified Highway fährst und feststellst, das ein kurzes Verbindungsstück nicht befahrbaren werden darf, erkennt man den Sinn von redundanten Tagging.

Vorher zu wissen, das auch OSM nicht weis, hat seinen Wert.

Eine “shoulder” ist nicht gleichbedeutend mit einer Standspur. Auch wenn das Wiki seit 3 Monaten etwas anderes behauptet.
Eine Shoulder ist ein befestigter Seitenstreifen neben der regulären Fahrbahn. Den gibt es auch auf unzähligen Nebenstraßen und muss (in DE) von langsamen Fahrzeugen verwendet werden. Für Radfahrer eine sinnvolle Information, ob eine recht schmale Straße ohne Radweg doch einigermaßen sicher benutzt werden kann.

So etwas sollte also in jedem Fall erfasst werden, und ist eine wertvolle Information.

Das finde ich einfach schlecht. Auf Github kann man diskutieren, ob die Bedienfelder grün oder gelb aussehen sollen oder oben/unten angeordnet sein sollen, aber Dinge die OSM an sich betreffen, gehören hier her oder auf die mailing Liste.

Dem kann ich nur beipflichten.
Begründet wird das immer damit, dass man ja dann weiß, ob jemand da nachgesehen hat. Das ist falsch. Wenn jemand nachgesehen hat, muss das mit Datum dokumentiert werden. Wenn jemand festgestellt hat, das der Zustand sich nicht verändert hat, wird an dem Datensatz nicht geändert. Also wird wieder und wieder nachgesehen, ob sich etwas verändert hat oder auch nicht. Das hat dann gar nichts mit Qualitätskontrolle zu tun, sondern dient nur dem “Geschäftsmodell” von SC.
Ein “xxx=no” gehört nur in die Datenbank, wenn es eine Regel gibt, die das vorschreibt. Wenn etwas physisch nicht vorhanden ist, ist es sinnlos, das zu taggen.

Pauschale Aussagen sind immer falsch und 67,943562% alle Deutschen können keine Prozentrechnung.

Bei Feldwegen bis hoch zu residential oder noch höher etc. kann man no als defaultwert sehen, bei Autobahnen etc. ist nicht gesetzter shoulder “immer” unbekannt (weil yes “Standard” ist.
Mal als Beispiel die A4 in Thüringen: https://overpass-turbo.eu/s/1i0b - wären diese nicht gesetzt, dann müsste man davon ausgehen, es gäbe welche.

Also explizit kein Stand/Notstreifen? Das ist mir grad neu.

Und jetzt schaue man bitte nach, wer in den letzten drei Monaten das engl. Wiki editiert hat…

Version VOR dem 03.01.2022:

aktuelle Version:

Noch mal separat herausgegriffen:

Natürlich steht im zweiten Satz noch “kann nützlich sein” - aber Hand aufs Herz: wieviele haben da schon nach dem ersten Satz aufgehört zu lesen (und in der App wird gar nicht darauf hingewiesen)? Da war die vorherige Formulierung besser, weil eher deutlich wird, dass es ein shoulder=no nicht unbedingt braucht.

Und grundsätzlich finde ich es keine gute Idee, wenn sich ein Maintainer das wiki so anpasst, wie es für seine App geschickt ist. Und dieser Eindruck entsteht bei mir nicht zum ersten mal (und ich bin selber Nutzer von SC).

Wie ich in meisten Nachtrichten lesen kann sehen hier viele auch ein fehlerhaftes vorgehen durch Streetcomplet / überflüssiges nutzen von *=no tags

Da ich von GitHub auch keine ahnung habe könnte das vieleicht jemand von euch dort melden.

Ich finde die *=no-Tags nicht überflüssig. OSM hat halt das Problem, dass es an vielen Stellen ziemlich löchrig ist und an anderen Stellen sehr detailliert.

Wenn ich mir z.B. eine Beleuchtungskarte von Deutschland erstellen will, kann ich nicht beurteilen, ob eine bestimmte Stelle tatsächlich dunkel ist, oder es nur an fehlenden Daten liegt. Eine sinnvolle Auswertung der Beleuchtungskarte ist damit oft unmöglich.

Und, wenn es beim “lit”-Tag sinnvoll ist “lit=no” zu setzen, warum dann nicht auch bei anderen Tags? Soll “=no" erst ab einem bestimmten zu erwartenden Anteil von "=no” getaggt werden?

Nein, inklusive. Die bisherige Definition von shoulder deckt sich im wesentlichen mit der Definition eines Seitenstreifen in der deutschen StVO.
Seitenstreifen kann es an allen Straßen geben, auf Autobahnen gelten nur einfach noch weitere Einschränkungen, die ihn zu einem Nothaltestreifen machen.

Grob zusammenkopiert:

Ich möchte hier weniger die Verwendung von shoulder=no kritisieren (die ich persönlich aber für überflüssig halte), aber etwas zum Verständnis des Begriffes beitragen. Ich komme ja von einer Baufirma, die u.a. auch ein paar Tausend KM Straßen gebaut hat.

Der Begriff “shoulder” beinhaltet sowohl das, was wir in Deutschland als “Bankett” (das ein konstruktiver Bestandteil jeder Straße ist) kennen, als auch das, was bei uns “Seitenstreifen” (eine Zusatzfläche zwischen der eigentlichen Straße und dem Bankett, die vorhanden sein kann, aber nicht muss) heisst. Ein Seitenstreifen kann unterschiedlich breit sein (von <1m bis >4m), befestigt, teilbefestigt oder komplett unbefestigt. Wenn er unbefestigt ist, kann er trotzdem ggf. befahrbar sein (feste Grasdecke) oder auch zu weich dafür (ggf. dann mit Schild “Seitenstreifen nicht befahrbar”), oder auch mit Gestrüpp bewachsen.

Wenn der Seitenstreifen durchgehend befestigt und für das Anhalten von Fahrzeugen vorgesehen ist, spricht man von einem “Standstreifen”.

Eine Ausserortsstraße ohne Seitenstreifen besteht aus Fahrbahn, Randstreifen (ein paar zusätzliche cm Asphalt um ein Ausbrechen der Ränder zu vermeiden) und Bankett.

Eine Ausserortsstraße mit Seitenstreifen besteht aus Fahrbahn, Seitenstreifen (befestigt, teilbefestigt oder unbefestigt) und Bankett.

Die Distanzbaken, Schilder und ggf. eine Leitplanke stehen im Normalfall auf dem Bankett.

Die Unterscheidung zwischen Bankett und Seitenstreifen kenne ich aus dem englischen nicht, beides ist im Begriff “shoulder” enthalten. Man unterscheidet da nur zwischen “hard shoulder” = Bankett + befestigter Seitenstreifen und “soft shoulder” = Bankett mit oder ohne unbefestigtem Seitenstreifen.

Ein Taggen von shoulder=yes sagt daher erst mal überhaupt nichts aus. Um dem einen Sinn zu geben, müsste auf jeden Fall ergänzt werden, wie breit der nutzbare Teil ist, ob befestigt, teilbefestigt oder unbefestigt und falls unbefestigt, ob befahrbar oder nicht.

Eine ganz gute Übersicht dieser Begriffe gibt es hier: https://de.wikipedia.org/wiki/Stra%C3%9Fenquerschnitt#Seitenstreifen_und_Standstreifen

Das erscheint mir ein berechtigter Hinweis zu sein. Mir wäre derzeitig auch nicht klar, was ich als sholder=yes und was als sholder=no einordnen sollte.

Ist shoulder=* also auch wieder so ein Schlüssel, bei dem viele Mapper nicht wissen, was es denn eigentlich ist? Als vor ein paar Jahren mal jemand (in english) angeregt hat, “shoulder” zu mappen, habe ich mit dem Begriff nicht viel anfangen können. Viel schlauer bin ich jetzt auch nicht. Wenn man shoulder=no in D da setzten soll, wo ein Schild “Seitenstreifen nicht befahrbar” steht, dann wäre das wirklich die große Ausnahme. Wirklich interessant finde ich diese Information aber auch nicht. Wüsste nicht, wie ich das beim Routenberechnen bewerten soll.

Ich hänge mich mal an diesen Thread ran mit meiner Frage.

Gestern habe ich das schöne Wetter ausgenutzt und bin mit Streetcomplete losgezogen um die Karte weiter zu verbessern.
Beim Mappen der Shoulders bin ich mir aber im Nachhinein sehr unsicher, ob ich das korrekt gemappt habe.

Wir haben eine Hauptstraße wo neben der Straße 1,5 bis 2 m Pflastersteine (oder eher Rasengitter?) kommen und anschließend ein Fuß/Radweg.
Diese Fläche ist jedoch nicht explizit als Standstreifen ausgewiesen.

Zählt hier ob es möglich ist neben der Straße anzuhalten oder ob es als Standstreifen ausgewiesen ist?

Hier ein Bild, welches ich in einem anderen Zusammenhang (https://www.openstreetmap.org/note/3174477) aufgenommen habe:

Der blaue Scooter steht auf dem Fuß/Radweg. Links oben ist im Ansatz die Straße zu sehen.

Wo wir gerade bei dem Bild sind, was würdet ihr als surface eintragen? Eher paving_stones oder eher grass_paver wegen den großen Abständen zwischen den Pflastersteinen?

Das sind Pflastersteine, siehe note.

Ist das innerorts? Hast du ein seitliches Bild, wie das im Kontext aussieht?
Bei uns kenne ich eine Straße mit einem solchen “Streifen” (immer mal wieder durchbrochen durch Bäume), der zum Parken dient (aber nicht explizit dafür beschildert ist). Wäre dann meiner Meinung nach kein shoulder.

Wie du siehst ist es aber eh noch in Diskussion, was shoulder wirklich bedeutet.

Danke Map_HeRo für deine genauen Erklärungen. Ich war eigentlich kurz davor zu schreiben, dass man in OSM vermutlich nicht alle Details erfassen kann / sollte - und stattdessen eher das tagging auf emergency_lane (für asphaltierte Seitenstreifen) ändern könnte - aber die aktuelle Version der Wiki Seite (hauptsächlich editiert durch westnordost) beschreibt jetzt eher die Details, die du genannt hast (soft und hard shoulder).

z.B.:

Folgt man dem Schema “shoulder = Seitenstreifen + Bankett” ergibt sich meiner Meinung nach folgendes:

  • das Quest in SC sollte geändert werden:
    • statt ja / nein
    • müsste es dort heißen: befestigt / unbefestigt (geeignet zum halten) / unbefestigt (zum halten ungeeignet) / nein
      • mit den Werten shoulder=yes+shoulder:surface=paved / shoulder=yes+shoulder:surface=unpaved / shoulder=no+verge=yes / shoulder=no+verge=no
      • alternativ wie im wiki diskutiert: shoulder=paved / shoulder=unpaved / shoulder=no+verge=yes / shoulder=no+verge=no
  • wobei ich mich frage, wie man “unbefestigt (geeignet zum halten)” und “unbefestigt (zum halten ungeeignet)” sicher unterscheiden kann

Die Diskussion wird/wurde auch an anderen Stellen geführt:

Interessant ist vielleicht auch der Hintegrund für die Einführung des tags (laut wiki) zwecks Interesse für Radfahrer. Da wäre mein Vorschlag emergency_lane=yes/no eindeutiger.
Hier ist der initiale github issue zum shoulder quest in SC.