Ist oneway=no sinnvoll?

  1. Bitte nutze einen aussagekräftigeren Threadtitel, z.B. “Ist oneway=no sinnvoll?”

  2. in konkreten Einzelfällen würde ich es als OK erachten. Sieht auch das Wiki so:

Es gab mal automatisch generierte Fehlerhinweise von irgendeinem Navi-Software-Hersteller, in der Art von “Hier fahren fast alle nur in eine Richtung, kann mal jemand schauen ob das eine Einbahnstraße ist?”

Für solche Fälle ist es hilfreich ein explizites “oneway=no” zu haben damit der entsprechende Bot keine weiteren false positives rauswirft.

Ja, bitte mal per “Eingangspost editieren” ändern, ggf. noch irgendetwas mit “StreetComplete” und “lanes <= 1” ranschreiben.

Generell hängt die Frage wohl mit einer StreetComplete-Aufgabe zusammen. Wurde hier nebenan und folgende Meldungen auch angesprochen (tritt z.B. dann auf bei lanes <= 1)

Zur den wiki Ausnahmen für die Stellen wo oneway=no interessant sein könnte. Das dort betreffende Gebiet:
https://www.openstreetmap.org/#map=17/51.00432/13.66958
stellt wohl keinen Bereich dar, wo Einbahnstrassen überwiegend vorherrschend sind und es betrifft auch keinen separat erfassten Autobahnabschnitt (highway=motorway & oneway=no).

Ob Wegsegmente die lanes=1 tragen auch zur Ausnahme zählen bin ich mir unsicher…

Edit: bzgl. lanes=1: Zumal die Wegabschnitte die in OSM gerne mal als lanes=1 erfasst werden nicht immer so klar sind und dieses Erfassungsschema daher auch immer mal besprochen/angepasst wird, siehe Beispielbilder 3 und 4 (https://wiki.openstreetmap.org/wiki/Key:lanes#Examples) Diese Fälle sind dort derzeit keine lanes=1. Wurden aber früher mal als lanes=1 erfasst?

Ich halte oneway=no an lanes=1 für wichtig, dann kann nämlich ein Sesselmapper oder ein QA-Tool oder vielleicht auch ein Router davon ausgehen, dass ein Ortskundiger nicht möglicherweise oneway=yes vergessen hat.

Aus dieser Logik heraus volle Zustimmung, aber wo wird lanes=1 gesetzt? Hast Du zufällig ein Beispielbild? In der oben genannten Liste ( https://wiki.openstreetmap.org/wiki/Key:lanes#Examples ) fehlt ein Beispiel mit lanes=1.

gemacht - danke.

Ich lass es einfach wie es ist. Danke.

Oben im ersten Beitrag. Kein Bild, aber lanes=1 lässt sich am Luftbild gut erahnen.
Foto von woanders:
https://www.mapillary.com/app/?focus=photo&pKey=TqYAHkmUBFGmFfsB3b5ADg oder noch woanders:
https://www.mapillary.com/app/?focus=photo&pKey=H95aJeHt-dyKEbcQvY2VAA

Nachtrag: gibt aber auch viel Murx in der Richtung. Ich hab ein paar Stichproben gezogen und da ist ein drittel wirklich falsch.

Danke!

Hatte auch diese Vermutung. Eben deswegen bin ich auch nicht so sicher, ob lanes=1 (lanes<=1) als Grundlage für die StreetComplete-Aufgabe: “Is this a one-way street?” geeignet ist.

Wie immer: wir haben mein Tagging für “unbekannt” sondern neu eingezeichnete Objekte werden automatisch mit den Standartwerten für alles was nicht explizit anders gemappt ist, interpretiert.

Eine Wiederholung des Standartwertes erzeugt nun viel, was wie Datenmüll aussieht aber immerhin die Information enthält “auf diesen Aspekt hin geprüft”.

Und wann und wo diese “ist überprüft” Info wichtig ist, ist nicht wirklich geregelt. Extremfälle sind noch jedem einsichtig, aber letztlich haben wir das selbe Problem bei vielen Tags wie “noexit” und soweiter…

Allgemein: Je mehr Tools eingesetzt werden, die nach Vollstaendigkeit fragen, desto mehr Sinn ergeben negative Tags eben um die False-Positives aus deren Auswertung zu bekommen.

Ich hab mal in Thüringen die entsprechenden Strassen geprüft und ein paar korrigiert, war doch nicht so viel Murx. (Abfrage)

Ich hab ein paar “einspurige” Strassen gefunden, die breiter als 5m sind (hab ich so gelassen) und da fällt mir auf, dass sich das deutsche und das englische Wiki mal wieder nicht ganz einig sind:

vs:

Weiter unten gibt’s dann nochwas zu “narrow roads” wo narrow durch die Blume mit 4m “definiert” wird.

Ich habe jetzt nach der Diskussion nebenan für StreetComplete v24.1 herausgenommen dass für Straßen mit lanes<=1 nach einer Einbahnstraße gefragt wird sondern nur wenn sowohl width als auch lanes darauf hindeuten dass es eine sein müsste.

Grund war vor allem dass die Datenqualität vom lanes-Tag insbesondere bei lanes<=1 offenbar nicht besonders zuverlässig ist.

Also ich als alter Mapper würde an eine Straße als zweites oneway=* setzen, bevor ich widht=* oder lanes=* ergänze. Früher hatte ich solche schmalen Gassen als service=* eingetragen - was angeblich falsch ist, da es ja Häuser an der Gasse gibt und deshalb ein *=residential sein muss. Besonders im Gebirge habe viel Zufahrten eine Breite von ca. 3m mit und das war dann lanes=1, also eine Straße ohne (Fahrbahn-) Markierungen.

Natürlich sind solche “APP’s” die nur einen Schlüssel abfragen und eintragen dann im Nachteil, wenn sie nicht alles bisher eingetragenes anzeigen. Das wäre der richtige Weg - dann Vorschläge nach weiteren Schlüsseln zu zeigen: lit=, surafce=, …

EDIT auch gerade gesehen:
https://www.openstreetmap.org/changeset/84535305#map=14/51.0568/13.5270
access=yes an Parkplätze? Dann wäre sinnvoller wo auch Stellflächen für Eltern und Behinderte sind, was für eine Oberfläche, frei oder bezahlt, …

Wenn ich dich richtig verstehe würde das (oneway=* setzen bevor width und lanes bekannt ist) dann ja bedeuten dass oneway=no an praktisch jede Straße per StreetComplete gesetzt würde, da lanes und width bisher an wenigen Straßen gesetzt ist. Das will man ja aus verschiedenen Gründen nicht.

Parking access ist grad bisschen off-topic, mögliche Werte sind öffentlich, für Kunden, privat. Wird erfragt weil viele Parkplätze von Luftbildern gemappt werden und es daher gut sein kann dass ein Parkplatz nicht gänzlich öffentlich ist. Frei oder bezahlt wird auch abgefragt, separat. Behinderten-Parkplätze (bisher) nicht weil wir uns nicht sicher waren ob das nicht massiv zu Spam führt, da in einigen Ländern es einfach Pflicht ist, dh. Alle relevanten Parkplätze haben das sowieso, andere Länder garnicht.

+1

Allein schon jeder verkehrsberuhigte Bereich wäre quasi lanes=1. Trotzdem muss man nicht jede dieser Straßen mit oneway=no taggen.

Das meine ich - alles wird separat abgefragt. Wenn ich wo bin kann ich alles eintragen, was ich sehe. So mache ich es jedenfalls (nach Gedächtnis und Foto).

Warum nicht:
"Ich stehe an der Straße “Am Schloßgarten”.
Dort ist eingetragen - ist das richtig:
highway=residential
lanes=1
name=Am Schloßgarten
surface=asphalt
Ergänze:
width=?
access=?
oneway=?

lit=?
eventuell:
traffic_sign=*

Eine Tabelle wie die solche zu befüllen, also ein Preset-Formular, ist sicherlich effizienter. So funktionieren JOSM, Vespucci, iD, GoMap usw.

Priorität #1 beim Design von StreetComplete ist halt nicht Effizienz sondern Einfachheit. Die Hürde, etwas beizutragen, soll für Gelegenheitsmapper so gering wie möglich sein. Das ist dadurch realisiert, dass die Möglichkeiten etwas zur Karte beizutragen in möglichst kleine “Häppchen” aufgeteilt sind, eben in diese separaten Fragen.
Obwohl es sicherlich effizienter ginge, schneidet die App im Punkto Effizienz im Vergleich zu Photo-Mapping (, Walking papers usw) garnicht so schlecht ab. Grund ist, dass eben die Dateneingabe am PC wegfällt, was ja durchaus erfahrungsgemäß oft nochmal so lange dauern kann wie die Begehung an sich. Dennoch, die Zielgruppen von StreetComplete sind weniger die erfahrenen Craft-Mapper (dafür gibt es schon Vespucci, JOSM, …), sondern Einsteiger und Gelegenheitsmapper.

Wenn du ein Android-Gerät hast, könntest du dir mal https://github.com/MichaelVL/osm-focus anschauen. Ich kenne aber genug StreetComplete Nutzer die auch Craft-Mapper sind, vielleicht solltest du die App auch mal ausprobieren.

war ein nettes Tool, funktioniert nur nicht mehr.

+1 :slight_smile:

Vielleicht könnte vorher das
https://github.com/westnordost/StreetComplete/issues/856
abgefragt werden :slight_smile:

Stichwort: unechte Einbahnstraßen.

Da ergänze ich idR auch ein oneway=no um falschem Mapping vorzubeugen. :slight_smile: