Straßen ohne Rad- oder Fußweg: cycleway:both=no, sidewalk:both=no?

Hallo zusammen,

es wurde schon kurz beim StreetComplete-Thema diskutiert, würde das aber gerne nochmal generell ansprechen:

Meiner Meinung nach würde es Sinn machen, Straßen (insbesondere außerorts) entsprechend zu taggen, wenn man festgestellt hat, dass diese keinen Rad-/Fußweg haben. Immerhin stellt sich mir die Frage, wenn kein Rad-/Fußweg eingetragen oder eingezeichnet ist, ob da wirklich keiner ist oder einfach nur fehlt.

Kann man machen, wobei ich etablierte Tags bevorzuge:

sidewalk=no - 398.000 mal in Verwendung :slight_smile:
sidewalk:both=no - 32 mal in Verwendung :frowning:

Wenn ich mich bei uns in der Gegend umsehe, simd Strassen ausserhalb von Ortschaften eher in der Regel ohne Geh- und Radwege.

Oh ja, danke.

Das englische Wiki führt das auch bei cycleway auf:

https://wiki.openstreetmap.org/wiki/Key:cycleway

Bei cycleway ist der Unterschied aber nicht ganz so krass:

cycleway=no 221.997
cycleway:both=no 98.129

Die both Schreibweise ist mathematisch mehrdeutig:

Die Straße hat nicht auf beiden Seiten einen Bürgersteig, könnte sie denn nur auf einer Seite einen Bürgersteig haben??? :stuck_out_tongue:

Dieses “both” ist sowieso doof. Wir taggen doch auch nicht maxspeed:both, surface:both usw.

Angeblich soll es die Überprüfung beider Seiten betonen, finde ich jetzt nicht so toll irgendwie sa wieder so was Weiteres mit diesem “both”…

+1

Zeit für nen Update:

cycleway=no 273.279
cycleway:both=no 896.782

Mit dem im Wiki empfohlenen einfachen cycleway=no statt cycleway:both=no könnte man also immerhin 4,5 MB sparen. :minidisc: :wink:

1 Like

sidewalk=no - 976.295 (+145 %)
sidewalk:both=no - 14.556 (+45387 %)

Na ja, wenn ich ein sidewalk=separate sehe, was heißt das? Auf beiden Seiten einer? Mindestens einer? sidewalk:both=separate ist da eindeutiger.
Bei sidewalk=no würde ich davon ausgehen, dass da immer beide Seiten gemeint sind, aber ich finde im Falle von yes oder separate das both besser.

1 Like

Bei “yes” kann ich es ja noch halbwegs nachvollziehen…

Bei “separate” eher weniger. “separate” heißt einfach, dass der Bürgersteig separat kartiert ist. Auf welcher Straßenseite ein Bürgersteig existiert, darüber sagt “sidewalk=separate” erst einmal gar nichts aus, dafür ist ja dann der Bürgersteig eben gerade separat kartiert.

Für den Fall dass eine Str. auf beiden Seiten einen Bürgersteig hat und davon aber nur einer separat kartiert ist, kommen natürlich die “left/right”-Tags wieder ins Spiel, klaro.

Ich meine, natürlich kann man das “both” verwenden. Es verbietet einem ja keiner.

Aber das “Problemchen”, das eigentlich dahintersteckt, ist meiner Meinung nach noch ein ganz anderes und zwar, dass StreetComplete in so vielerlei Hinsichten etablierte bzw. jahre- bis jahrzehntelang bis auf Kleinigkeiten relativ problemlos verwendete Taggingstrukturen über den Haufen wirft,
und OSM allein durch die hohe Anzahl an Nutzern der App die eigenen Taggingregeln aufzwingen will. Ganz im Sinne von “die Anahl der Verwendungen zählt ja, und die kriegen wir mit einmal in der App eingebautem Tagging prima hoch.” Ich weiß, dass das jetzt wieder diverse Diskussionen auslösen könnte und jede Seite hat sicherlich ihre guten Argumente. Es ist auch schon zig mal diskutiert worden und man kommt dagegen sowieso nicht an. Ich sehe es ja ein.

Aber dennoch gibt es ein paar Eindrücke, bei denen ich manchmal die Gegenseite nicht verstehe, warum alles zwei- und fünfmal getaggt werden muss.

In D (ich sage bewusst in D, nicht auf der ganzen Welt, aber trotzdem) hat man vor SCs Hoch-Zeiten Manches einfach anders gemacht:

  1. Bei Hauptstraßen konnte man früher davon ausgehen, dass die surface wohl asphalt sein wird, außer halt sie ist explizit anders getaggt. Heute haben wir alles explizit und mindestens 90% der größeren Straßen in D werden “asphalt” sein.

  2. cycleway hieß früher cycleway, auf beiden Seiten, außer halt explizit nur als cycleway:right oder :left getaggt, oder an einer Einbahnstraße. Sonst hieß cycleway einfach cycleway auf beiden Seiten, fertig.

  3. Früher wurde nicht jede residential mit cycleway-Tags versehen, wenn eine reseidential kein cycleway-Tag hatte, dann konnte man in 95% der Fälle davon ausgehen, dass sie keinen cycleway hat. Sonst wäre der in den allermeisten Fällen schon getaggt gewesen. Fertig.

  4. Nicht an jede grit_bin musste ein “seasonal”. seasonal kommt bei grit_bins btw gar nicht mal soo häufig vor, die meisten, die ich gesehen habe, stehen das ganze Jahr über dort. Heute muss alles explizit getaggt werden.

  5. Bei einem punktförmigen Überweg (highway=crossong) war zunächst anzunehmen, dass dieser keine Mittelinsel hat - außer halt, sie wurde explizit angegeben. Heute erhalten ALLE Überwege ein crossing:island-Tag und bei den tausenden von “Kleinstüberwegen”, die SC abfragt, ist die Antwort fast immer crossing:island=no.

  6. Und diesen Punkt finde ich ganz besonders auffallend:
    Bei getrennten (aber nebeneinander verlaufenden, segregated) Fuß- und Radwegen hieß surface einfach surface. Für BEIDE Wegearten. In 80-90% der Fälle haben der Geh- und der Radweg ohnehin die gleiche surface. Aber SC erkennt ein surface-Tag an Wegen mit segregated=yes nicht einmal an!!! Nein, da muss dann immer nach footway:surface und cycleway:surface aufgeteilt werden. Immer. Wenn die surface unterschiedlich ist, ist das verständlich - aber ansonsten überhaupt nicht. Warum einfach machen, wenn es auch kompliziert geht.

  7. check_date wird zum reinen Existenzprüfdatum degradiert - ob jemals danach noch irgendwelche anderen Tags auf ihre Stimmigkeit/Aktualität hin mit geprüft wurden, spielt keine Rolle mehr. Dabei suggeriert check_date eine Aktualität. Wenn man nur die reine Existenz an sich prüft, sollte es besser eine Art Under-Tag von check_date geben (meine Meinung).

Und das ist dasjenige, was eigentlich hinter der Kritik steckt. Es wird zwar auf GitHub, Tagging usw. viel diskutiert, aber am Ende entscheiden einige wenige Leute und zwar immer tendenziell in diese “alles explizit taggen”-Richtung. Sorry, dass ich das jetzt hier so raushaue, mir ist klar, dass das so nicht großartig konstruktiv ist. Nur ich habe schon so viel Fehlerbehaftetes von SC-Usern gesehen, so viele Notes, so viel Durcheinander…

2 Likes

Und dann auch diese ständige Aktualisiererei: Natürlich müssen manche Dinge regelmäßig geprüft werden, die Idee dahinter ist ja nicht schlecht, sondern super sinnvoll.

Gerade dieses “Kleinzeugs” wie Verkaufsautomaten zum Beispiel. Aber weil das so “Kleinzeugs” ist, wird da auch gerne mal was weggelöscht, was man nur gerade nicht gesehen hat. Oder man ist in einem Bahnhof oder Einkaufszentrum mit zig Ebenen.
Und dort soll dann die Existenz eines ganz bestimmten Automaten, Briefkastens ö. Ä. überprüft werden.
Das ist einfach nicht händelbar für den einfachen User, der nicht in der Materie drin ist. Zwei Klicks und schon ist irgendwas hochgeladen, Hauptsache was gemacht.

Aber die Überprüfung der an Recyclingcontainer-Standorten akzeptierten Materialien alle zwei Jahre? Wo ändert sich das so schnell?

Entweder ich bin ein Unternehmen, das an seinen Standorten neben Altglas z. B. auch Altpapier sammelt, oder eben nicht. Da wird nicht 2020 mal eben Altpapier mit eingesammelt, 2023 wird das wieder abgeschafft und 2025 kommen dann die kleinen Elektrogeräte hinzu, die 2027 wieder nicht mehr eingesammelt werden. Was ist das für eine Logik?

Und dann fragt Sc ausgerechnet das so oft ab, kommt aber mit einzeln kartierten Containern bzw. wegen der Einwurfzeiten separat kartierten Altglascontainern nicht klar. “Weil die User nicht nah genug heranzoomen, um die zu sehen”. Genau. Da wird es dann auf die (unwissenden/unschuldigen) User abgewälzt, wenn sie die App nicht bedienen “können”. Manchmal wäre es echt besser, SC würde von manchen Sachverhalten einfach die Finger lassen.

Geschätze widths lassen wir jetzt auch zu. Super. Als nächstes tragen wir dann geschätze Verkehrsaufkommen ein, oder wie? Entweder man hat ein Maßband dabei, oder man trägt keine width ein, fertig.

Und der nächste Thread mit SC-Bashing gekapert… :frowning: Kann man das nicht in einem Thread konzentrieren?

Meine Frage war ganz unabhängig von SC. Und ich tagge der eindeutig wegen gerne sidewalk/cycleway:right/left/both (manuell - früher mit iD, heute mit JOSM) . Wobei ich überlege statt :both einfach immer :right und :left zu verwenden. Aber das ist Geschmackssache.

Ist wsl. Geschmackssache :man_shrugging:

Das Thema lädt halt ein und insbesondere in Bezug auf cycleway:both=no und sidewalk:both=no ist die Erwähnung von SC ja richtig.

Im Unterschied zu SC werden bei iD und JOSM die Tags dargestellt. :both braucht es mMn nur bei Einbahnstraßen. Für alle anderen reicht auch cycleway=* und sidewalk=* solange auf beiden Seiten der gleiche Wert gilt, insbesondere mit no als Wert. Das ist auch eindeutig und wurde u.a. von SC aufgeweicht.

Dann meckert zu Recht aber Validator bei gleichen Werten, da ja ein Tag ausreicht. :slightly_smiling_face:

1 Like

Da meckert JOSM witziger Weise… “Gleicher Wert für cycleway:right und cycleway:left, dafür cycleway verwenden” :joy:

Wie so oft haben sich halt wieder mehrere Arbeitsweisen etabliert.
Für denselben cycleway gibt es vier Varianten:

  1. Die “Faulen” oder “Konservativen” taggen cycleway=track
  2. Die SCler taggen cycleway:both=track
  3. Die “Ausführlichen” taggen cycleway:right=track und cycleway:left=track
  4. Die “Ober-Ausführlichen” tragen den cycleway separat ein (idealerweise, ohne bereits vorhandene cycleway-Tags an der Straße zu berücksichtigen natürlich ^^)

Natürlich wird dann cycleway:both/right/left=separate getaggt! :slight_smile:

1 Like

Ja :slightly_smiling_face:

Mann bin ich froh, dass wir uns da einig sind.
Das soeben genannte “Problemchen” (cycleway an Straße und zusätzlich separat erfasst) ist mir in letzter Zeit gefühlt irgendwie tausende Male untergekommen.

Ich hatte schon fast so meine Zweifel, ob ich evtl. nicht mitbekommen hätte, dass es mittlerweile akzeptiert wäre, beides gleichzeitig zu taggen :joy:

(Ich glaub manche, wenn auch ganz sicher eine Minderheit, vertreten solch einen Standpunkt allen Ernstes).