Talk:Berlin/Verkehrswende/Fahrradparkplaetze

From OpenStreetMap Wiki
Jump to navigation Jump to search

Editor

Unsere Tagging Empfehlung

  • Alle Fahrradstellplätze eintragen, auch Kunden-Stellplätze und private Stellplätze (siehe access=*)
  • Einzelne Einträge erstellen für Gruppen von Stellplätzen die Räumlich zusammen gehören
    • Beispiel: Stellplatz <> Baum <> Stellplatz trennen in 2 Stellplätze, damit der Baum gesondert gemappt werden kann
  • Stellplätze erstmal als OSM-Punkte (Nodes) eintragen. Große Abstellanlagen können später in Flächen umgewandelt werden. Je nach Erfahrungsgrad gerne direkt als Flächen eintragen. Faustformal für Flächen: Capacity > 10.
  • Nur Stellplätze erfassen, die als solche gedacht sind. Keine Zäune/Geländer (in OSM barrier=fence+fence_type=railing) Schilder, Laternen, keine bicycle_parking=informal.
Tag Value Beschreibung
amenity=bicycle_parking Fix Haupt Tag. Wiki: Tag:amenity=bicycle_parking
bicycle_parking=*

Siehe Wiki. Üblich in Berlin sind …

Art des Fahrradständers. Wiki: Key:bicycle_parking.
capacity=* Zahl Anzahl Fahrräder. Wiki: Key:capacity Die Anzahl Fahrradständer erfassen wir nicht. Sie kann im Normalfall durch Typ und Kapazität abgeleitet werden. Ausnahmen davon ignorieren wir der Einfachheit halber.
covered=* yes, no Wiki: Key:covered
access=* yes, private, customers Angenommener Default ist „yes“. Wiki: Key:access
Optional: lit=* yes, no Wiki: Key:lit
Experiment: bicycle_parking:position=*
  • lane (Fahrbahn), auch ehemalige Auto-Parkplätze am Seitenstreifen
  • parking_lot (Parkbucht, baulich getrennt von Fahrbahn)
  • sidewalk (Bürgersteig)
  • driveway ((Grundstücks-)Zufahrt)
  • park (Park)
  • pedestrian_area (Bereich für Fußgänger)
  • Weitere Values denkbar.
Lagebeschreibung (Taginfo Values). Angelehnt an fire_hydrant:position=* (Taginfo). Ziel ist die Auswertung von Flächengerechtigkeit. Werden Fahrradstellplätze auf Kosten von Auto-Fläche, Fußgänger-Fläche, Erholungsfläche (Park), etc. erstellt. Overpass-Abfrage.

Keys die wir nicht besonders betrachten

  • Operator=* / Wiki: Key:operator - Erscheint uns zZ nicht relevant für unsere Anwendungsfälle
  • survey:date=* || Format: yyyy-mm-dd || Datum, wann der Fahrradständer zuletzt „gesehen“ wurde. Wiki: Key:survey:date
    • Meetup #3: Tag nicht wichtig. Und wenn, dann wäre noch nicht klar, ob survey:date der richtige ist.

TODOs Tagging Empfehlungen

Diskussionen

Diskussion: Mapillary + Osmose

Etwas Research. Ob sich daraus etwas relevantes für uns machen lässt, ist noch unklar IMO.

--Tordans (talk) 13:12, 7 July 2019 (UTC)

Diskussion: Pic4Review

--Tordans (talk) 13:12, 7 July 2019 (UTC)

Diskussion: Link zu Übersicht Radstellanlagen Neukölln

--Tordans (talk) 13:27, 7 July 2019 (UTC)

ARCHIV: Diskussion: Vorschlag zur Verwendung von access=*

Immer mehr Fahrradabstellanlagen befinden sich auf privaten Grundstücken und stehen nicht allgemein der Öffentlichkeit zur Verfügung sondern nur den Bewohnern der zugehörigen Gebäude oder Kunden von Geschäften. access=* sollte daher immer angegeben werden.

Hilfreich für die Fragestellung, ob sich eine Fahrradabstellanlage auf Privatgrundstücken befindet, sind für Berlin die Flurstücke des Liegenschaftskatasters https://daten.berlin.de/datensaetze/alkis-berlin-amtliches-liegenschaftskatasterinformationssystem

Es sollten generell nur Fahrradständer etc. eingetragen werden, die dauerhaft zur Verfügung stehen, und keine die z.B. nach Geschäftsschluss weggeräumt werden.

Prinzipiell kann man die Frage stellen, ob man nicht öffentlich nutzbare Fahrradabstellanlagen überhaupt erfassen sollte. Dafür spricht eine Datenbasis für die Versorgung mit Fahrradparken zu haben, dagegen spricht der eingeschränkte Nutzen für die meisten Kartennutzer. Dies könnte allerdings durch die Kartenanzeige gelöst werden und ist bei korrekter Anwendung von access=* eigentlich kein Problem der Datenerfassung und -haltung. --Ulid000 (talk) 12:39, 4 July 2019 (UTC)

Ergebnis Meetup: --Tordans (talk)

  • Access-Definition: So verstehen wir es auch
  • operator=* und operator:type=* erscheint uns erstmal zu komplex; ist nicht immer gut zu erkennen
  • Eintragung: Ja, alles, die dauerhaft stehen, auch private (mit Access)
  • Exkurs: Wie erfasst man Fahrradständer, die vor privaten Häusern sind (Beispiel Mapillary). Ergebnis: Als access=yes, da keine klare, räumliche Abgrenzung und keine Beschilderung.

ARCHIV: Diskussion: Fragestellungen zur Verwendung von bicycle_parking=*

Als Radfahrender interessiert mich primär, ob ich den Rahmen des Fahrrads an einem festen Gegenstand anschließen kann. Dies minimiert zum einen das Diebstahlsrisiko und stellt zum anderen die Einhaltung von Versicherungsbedingungen im Diebstahlsfall sicher. Das ist im Zweifelsfall wesentlicher als die exakte Bauform. stands ist die einzige verbreitete Form, aus der sich die Eigenschaft ableiten lässt, auch wenn es Varianten von rack oder wall_loops gibt, die ein sicheres Anschließen aufgrund von Positionierung oder Bauform erlauben.

Zusammenstellung zu verschiedenen Typen in Berlin: https://woesbeginnt.wordpress.de/2019/07/02/osm-radstellplaetze-in-berlin-typen/

  • Wie klassifizieren wir die Bauformen?
  • Wie schaffen wir eine Datenbasis mit der man Möglichkeiten zum sicheren Anschließen des Rahmens leicht finden kann und nicht nur alle Abstellmöglichkeiten?

--Ulid000 (talk) 12:39, 4 July 2019 (UTC)

Ergebnis Meetup:

  • Das Schema von bicycle_parking=* ist gut etabliert und auch einfach zu verstehen / mappen. Der Editor kann/sollte zusätzlich Fotos anbieten zum Abgleich. Die Frage des "wie schließe ich ab“ kann aus bicycle_parking=* abgeleitet werden. --Tordans (talk)

ARCHIV: Diskussion: Fragestellungen zur Genauigkeit der Erfassung und Verwendung von Node vs. Way (geschlossen als Fläche)

  • Unterscheidung über Fläche/Anzahl/Capacity als Daumenregel? Also z.B. ab 10/20 Rädern möglichst als Fläche, sonst als Node.
  • Nachteil von Flächen: Überlagerungen passieren schneller als mit Nodes und nicht nur das Bearbeiten wird schwieriger sondern auch die Anzeige kann dadurch unterdrückt werden. (Bushaltestelle, Telefonzelle, Fahrradbügel, ...)
  • Wie genau wollen wir die Position bei gruppiert angeordneten Fahrradabstellanlagen erfassen? 1 Eintrag mit 100 vs. 10 Einträge mit 10 und genauer Position.
  • Persönliches Beispiel: U-Bahnhof Krumme Lanke (Fahrradbügel an drei Ecken der Kreuzung, auf dem Vorplatz des U-Bahnhofes in vertrauten Gruppen, daneben und links/rechts des Fuß-/Radwegs daneben.) Ich würde instinktiv bei mehr als 10 m Abstand zwischen einzelnen Fahrradabstellanlagen diese getrennt erfassen. Mir ist aber nicht klar, welche Auswirkung das auf die Darstellung bei verschiedenen Maßstäben hat, da ja keine Zusammenfassung oder Generalisierung stattfindet meines Wissens. Da wäre es gut, die Auswirkung auf Kartendarstellungen zu kennen.

--Ulid000 (talk) 12:39, 4 July 2019 (UTC)

Ergebnis Meetup:

ARCHIV: Diskussion: Tagging-Idee: "wo ist der Stellplatz angebracht

Ideen:

- „consumed space“ - „used space“

Ergebnis Meetup:

ARCHIV: Diskussion: Tagging-Idee: "wer darf hier parken" / Lastenräderplätze

Ideen:

Notizen:

Ergebnis Meetup:

  • Erstmal abwarten, nicht relevant genug --Tordans (talk)

ARCHIV: Diskussion: Fahrradinfrastrukturbearbeitungswerkzeug

  • wenn das Tagging geklärt ist, wäre ein Editor nützlich mit dem die Daten erfasst werden können
  • JOSM und ID funktionieren dafür, sind aber nicht für jeden geeignet
  • https://zlant.github.io/parking-lane ist eine gute Vorlage, erlaubt aber bisher keine Erzeugung von Features
  • https://osmybiz.osm.ch ist ein POI-Editor mit dem auch neue Features angelegt werden können
  • ich habe mir beide angeschaut und osmybiz angepasst und möchte das Ergebnis und meine Erkenntnisse gerne vorstellen
  • Was mich noch interessiert: Wie sollte eine gute Fahrradkarte aussehen, welche Informationen sollen enthalten sein, unabhängig ob digital oder print.
  • Links über die ich noch gestolpert bin:

--Lars

Ergebnis Meetup:

  • Siehe oben: osmybiz auf dem Hackathon weiter anschauen --Tordans (talk)