(Organised Editing) Parkraumerfassung in Lörrach, Baden-Württemberg

Liebe OSM-Community insbesondere im Südwesten Baden-Württembergs,

seit einigen Jahren beschäftigen wir uns in der Berliner OSM-Community mit der Erfassung von Straßenparken in OSM. Mit dem OSM-Parkraumprojekt haben wir eine Methode entwickelt, wie sich mit OSM-Daten recht genaue Aussagen darüber ableiten lassen, wo sich in einer Stadt wie viele Parkplätze am Straßenrand befinden – vorausgesetzt, es gibt Daten dazu in OSM nach dem Schema zur Erfassung von Straßenparken.

Einige von uns entwickeln diese Methode inzwischen bei FixMyCity weiter, einem Unternehmen, das Kommunen bei der Digitalisierung im Bereich der Stadt- und Verkehrsplanung unterstützt. Wir möchten die Stadt Lörrach im Südwesten BaWüs gern dabei unterstützen, Parkraumdaten für ihre Kommune auf Basis von OSM zu erfassen und planen dafür ein Mappingprojekt in den nächsten Monaten (etwa von Oktober bis Ende des Jahres).

Was haben wir konkret vor? Wir möchten im ganzen Stadtgebiet von Lörrach 360-Grad-Straßenfotos erstellen, auf deren Grundlage wir anschießend vor allem Daten zum Straßenparken mit dem OSM-Street Parking-Schema ergänzen möchten. An jeder Straße erfassen wir also 1) ob und wenn ja, wo geparkt wird (z. B. auf der Fahrbahn oder auf dem Gehweg), 2) in welche Richtung die Fahrzeuge beim Parken ausgerichtet sind und 3) ob Gebühren erhoben werden oder andere Parkbeschränkungen gelten. Wo es welche gibt bzw. diese in OSM fehlen, erfassen wir auch Parkflächen abseits des Straßenraums mit Tags zur Zugänglichkeit/öffentlichen Benutzbarkeit und ggf. Parkbeschränkungen. Im Straßenraum möchten wir weitere Daten ergänzen und aktualisieren, die das Parken beeinflussen (wie Zebrastreifen/Fußgängerüberwege, Ampeln, Einfahrten oder Bushaltestellen). An besonders breiten oder schmalen Straßen möchten wir außerdem die Breite auf Basis von Orthofotos im Abgleich mit den Straßenfotos erfassen. Die Straßenfotos stehen der Community natürlich auch auf Mapillary (und hoffentlich irgendwann Panoramax) zur Verfügung.

Wenn ihr mehr darüber wissen wollt, was wir genau taggen wollen, wie wir das Vorgehen planen und welche Quellen zur Verfügung stehen, könnt ihr das auf der dazugehörigen Organised Editing-Seite erfahren.

Das Mapping möchten ich (Alex, OSM-User Supaplex030 bzw. in diesem Fall fmc_Supaplex030) und Mlvln / fmc_Mlvln übernehmen. Wir haben beide jahrelange OSM-Erfahrung, nicht zuletzt auch bei der Parkraumerfassung. Im Gegensatz zu einem größeren Parkraumprojekt im letzten Jahr in Berlin planen wir in – im Vergleich zu Berlin doch recht kleinen – Lörrach nicht, ein Mapping-Team einzubeziehen und zu schulen. Dieses Projekt aus Berlin ist übrigens ein schönes Beispiel, wie man mit etwas Überzeugungsarbeit Verwaltungen dazu bewegen kann, OSM aktiv zu nutzen und zu unserem “Ökosystem” beizutragen.

Soweit unser geplantes Vorhaben. Wir freuen uns über eure Rückmeldungen und tauschen uns gern darüber aus, falls es Bedenken oder Nachfragen gibt.

Wir kündigen das Mapping-Projekt hier im Forum an und kontaktieren darüber hinaus aktive Mapper:innen in Lörrach. Es gibt eine lokale Mailing-Liste für Baden-Württemberg, die aber – soweit wir sehen – nicht genutzt wird und auf der kaum jemand steht. Falls jemand noch Ideen oder Hinweise hat, wen wir lokal/vor Ort einbinden können, sind wir über Hinweise dankbar!

Darf man davon ausgehen, dass ihr nicht eintragen wollt wo geparkt wird sondern nur wo man das auch darf?

Richtig. Siehe Projektseite im Wiki.

Bei der Erfassung gehen wir von der rechtlich zulässigen Situation aus, erfassen Falschparken also nicht als Parkraum in OSM.

Habt ihr vor alle Einfahrten zu mappen, oder nur, wenn es absolut notwendig ist?

Aus Parkraumsicht ist es nur dann „überflüssig“ wenn man dort sowieso nie parken darf, wegen expliziten Verboten oder impliziten (Bushaltestelle, Kreuzungsnähe, etc.), sonst ist es immer „absolut notwendig“

Wir erfassen Einfahrten, wenn sie als Zufahrt für Kfz genutzt werden / genutzt werden können und versuchen uns im Zweifelsfall an folgenden Merkmalen zu orientieren: Es gibt einen abgesenkten Bordstein zur Straße; die Einfahrt ist baulich angelegt und breit genug für ein Kfz (>= 2,5m); die Benutzbarkeit ist erkennbar oder ein Schild bekräftigt den Willen, dass es sich um eine freizuhaltende Einfahrt handelt (wie bei Feuerwehrzufahrten).

Einfahrten mappen wir als highway=service, meist mit service=driveway, wenn sie der Erschließung einzelner Grundstücke dienen. Wenn der Verlauf ab der Grundstücksgrenze auf Luftbildern oder Straßenfotos erkennbar ist und eine gewisse Relevanz gegeben ist (z. B. als Zuwegung zu einem zurückgesetzten Gebäude), ab der Grundstücksgrenze weiter üblicherweise mit access=private (wenn keine öffentliche Benutzbarkeit z. B. zu einer Arztpraxis o. ä. vorliegt). Sehr breite Einfahrten (z. B. in Gewerbegebieten) erfassen wir mit ihrer Breite (width) oder erfassen an ihrer Straßeneinmündung linear abgesenkte Bordsteine mit barrier=kerb + kerb=lowered.

Rechtlich gibt es Graubereiche, wenn die Nutzbarkeit von Einfahrten nicht mehr klar erkennbar ist – selbst wenn es abgesenkte Bordsteine gibt, sanktionieren viele Ordnungsämter beispielsweise das Parken vor Einfahrten nicht, wenn deren Benutzbarkeit fraglich ist. In Städten begegnen einem erfahrungsgemäß allerhand “Edge Cases” wie “alte” Einfahrten, die offensichtlich nicht mehr als solche genutzt werden können: Also wo es zwar abgesenkte Bordsteine und bauliche Merkmale wie z. B. gepflasterte Gehwegüberfahrten gibt, aber dahinter kommt z. B. eine schmale gewöhnliche Haustür oder eine Mauer. Sowas erfassen wir nicht als Einfahrt.

Da wären noch ein paar Korinthen:
Straßenverkehrs-Ordnung (StVO) § 12 Halten und Parken
(3) Das Parken ist unzulässig

  1. vor und hinter Kreuzungen und Einmündungen bis zu je 5 m von den Schnittpunkten der Fahrbahnkanten, soweit in Fahrtrichtung rechts neben der Fahrbahn ein Radweg baulich angelegt ist, vor Kreuzungen und Einmündungen bis zu je 8 m von den Schnittpunkten der Fahrbahnkanten,
  2. wenn es die Benutzung gekennzeichneter Parkflächen verhindert,
  3. vor Grundstücksein- und -ausfahrten, auf schmalen Fahrbahnen auch ihnen gegenüber,
  4. über Schachtdeckeln und anderen Verschlüssen, wo durch Zeichen 315 oder eine Parkflächenmarkierung (Anlage 2 Nummer 74) das Parken auf Gehwegen erlaubt ist,
  5. vor Bordsteinabsenkungen.

Es ist rein rechtlich völlig irrelevant, ob die Einfahrt noch genutzt wird oder nicht. Vor Bordsteinabsenkungen ist Parken verboten.
Wer mal mit Kinderwagen oder Rollstuhl unterwegs war weiß das zu schätzen. bzw. er wüsste es zu schätzen, wenn sich da jemand dran halten würde…

Ja, solche fitzelchen mappe ich auch manchmal, wenn ich die sehe, als footway, der zur centerline verbindet. Das ist fürs fußgängerrouting wichtig. Genauso wie dann auf der ggü. liegenden Seite das weoter zu führen, wenn möglich, z.B. an eine Einfahrt anbinden.
Manche Fußverkehr-Router nehmen das mit der verbotenen fahrbahn da sehr eng, und dann bringt das doch wieder nix, da auch die 1–2 Meter da nicht benutzt werden um doch zu queren.

Auch wenn separate Wege “irgendwo” eine Straße queren kann ein Bordstein dort abgesenkt sein, gerade da wäre es schön, wenn da keiner parkt (und das gemappt ist sowieso)

Ansonsten glaub ich ist es schwer nur von 360° Bildern jeden abgesenkten Bordstein zu finden, oder richtig zu verorten, vor allem wenn da halt immer wer vor parkt. Bei Einfahrten ist das einfacher.

Dem stimme ich zu. Das macht die Erfassung auch einfacher, weil “Bordsteinabsenkung vorhanden Ja/Nein” ein objektives Kriterium ist.

Und:

Bei der Erfassung gehen wir von der rechtlich zulässigen Situation aus, erfassen Falschparken also nicht als Parkraum in OSM.

Ich sehe diese Parkraumerfassung sehr kritisch, insbesondere den Abschnitt “Separat gemappte Parkplätze im Straßenraum”. Das hier dokumentierte Tagging jedes einzelnen straßenbegleitenden Parkplatzes als amenity=parking ist falsch.

Ein Parkplatz ist eine einzelne, größere Fläche, mit mehreren Stellplätzen für Pkw, auf der Kunden oder die Öffentlichkeit ihr Fahrzeug für eine gewisse Zeit abstellen können - so auch das massgebende englische Wiki. Die Fläche wird dabei gem. Wiki mit amenity=parking und der einzelne Stellplatz kann mit amenity=parking_space gemappt. Jeden einzelnen (möglichen) Stellplatz entlang einer Straße als amenity=parking zu mappen ist somit falsch. Bei parallel zur Straße erlaubten Parken sind einzelne Stellflächen oftmals auch nicht markiert - die mögliche Anzahl Parkplätze hängt dann davon ab, ob da ein Smart oder ein Caravan steht, oder auch ein Bootsanhänger abgestellt wurde.

Mittels des Organised Editing wird hier nach und nach ein Flächenmapping durchgesetzt, das - nach eigener Erfahrung - auch einer Überprüfung vor Ort oftmals nicht standhält und der Realität nicht entspricht. In Berlin wurden einzelne Parkplätze neben der Straße gemappt, die weder markiert, noch ausgeschildert sind, auf denen aber im Luftbild oder zum Zeitpunkt der eigenen Straßenaufnahmen geparkte Autos standen. Das Autos nicht immer korrekt geparkt werden, wurde dann beim Mapping offensichtlich nicht bedacht.

Das Ergebnis: In Berlin gibt es nun ganze Straßenzüge die mit blauen Ps in der Karte übersät sind. Für den Nutzer der Standardkarte nicht besonders schön - aber wir mappen ja nicht für den Renderer ;-)

Allerdings wird auch die Suche nach einem Parkplatz in jeder OSM-Anwendung nunmehr mit einer ellenlangen Liste einzelner straßenbegleitender Stellplätze beantwortet. Das macht die Navigation zu einem echten Parkplatz äußerst schwierig bzw. eigentlich unmöglich. Der Otto-Normal-User wird nur den Kopf schütteln und das Weite suchen … also die OSM-App nie wieder nutzen.

Warum? Du kannst ja parking=street_side herausfiltern, wenn Du nicht an einer Straße parken möchtest, was Du wohl mit “echtem Parkplatz” meinst.

Ich kann das - aber die Apps machen das halt nicht. Und das ist für die User das relevante.

Das parking:side=street_side ist nicht das Problem, sondern die separat gemappten Stellflächen als amenity=parking. Die werden als Parkplatz (nicht Stellfläche/Stellplatz) in den Apps ausgewertet. An den Straßen wurde dann hier konsequent parking:side=separate ergänzt und damit geht die generelle Information zum straßenbegleitenden Parken verloren.

Gab es da nicht schon mal eine Diskussion um inflationäres Parkplatz-Micromapping?

diese Information geht nicht verloren weil an den separat gemappten Flächen parking=street_side gemappt wurde, oder lane / shoulder / on_kerb / half_on_kerb und das nur, wenn diese Flächen entsprechend markiert waren.

Zusätzlich wurde street:name ergänzt und dadurch ein Bezug zur Straße hergestellt.

Einen “Parkplatz” wie du ihn hier beschreibst (im Sinne eines größeren Flächenparkplatzes) können wir in OSM vor allem über parking=surface differenzieren (oder davon ausgehen, dass ein amenity=parking ohne parking=* vielleicht einen solchen beschreibt). amenity=parking selbst ist jedoch einfach nur ein Primärtag, um irgendein Feature zu beschreiben, das sich zum Parken von (mehrspurigen) Kfz eignet. Was genau einen dort erwartet, wie groß er ist, ob es ein herkömmlicher Flächenparkplatz, eine Tiefgarage oder eine Parkbucht ist… beschreiben wir mit Subtags wie parking, capacity, access etc. Das Primärtagging eines Features von seinen Eigenschaften abhängig zu machen ist nicht zielführend und machen wir in anderen Bereichen von OSM ja üblicherweise auch nicht. (Ich vergleich es immer gern mit amenity=bicycle_parking: Beschreibt einen Ort zum Abstellen von Fahrrädern – das kann ein einzelner Fahrradbügel sein oder ein mehrstöckiges Fahrradparkhaus mit tausenden Fahrrädern drin.)

Ich kann aber deine Bedenken hinsichtlich des Mappings in Berlin nachvollziehen: Hier sind wir auch für meinen Geschmack insbesondere in randstädtischen Bereichen mit “informellem Parken auf dem Seitenstreifen” über das Ziel hinausgeschossen, da wir uns hier – im Gegensatz zu dem geplanten Projekt in Lörrach – an bestehenden Parkraumdaten orientieren konnten und es für das Mappingteam oftmals “bequem” war, hier die bestehenden Daten “nachzumalen”/zu übernehmen statt sie etwas aufwendiger an der Straßenlinie mit Hindernissen im Seitenraum nachzumodellieren. In Lörrach / bei “Neuerfassung” ist unsere Mapping-Philosophie im Gegensatz dazu: Wir erfassen Parken grundsätzlich mit parking-Tags an der Centerline und als separate Fläche (mit amenity=parking) nur, wenn wir dadurch häufiges Splitten der Centerline verhindern und die separaten Flächen auch on the ground baulich oder durch Markierungen abgrenzbar sind. Also insbesondere Parkbuchten oder einzelne markierte Stellplätze, deren Parkbedingungen vom Rest der Straße abweichen. Das entspricht dem inzwischen gängigen OSM Street Parking-Schema.

Das englische Wiki unterscheidet klar zwischen “parking lot” (= Parkplatz) → amenity=parking und “single parking space” (= einzelner Stellplatz) → amenity=parking_space. Somit wäre es gemäß dem standardgebenden englischen OSM-Wiki folgerichtig, dass wenn einzelne Parkplätze am Straßenrand gemappt werden, diese als amenity=parking_space getaggt werden. Dies würde dann die Useability von Apps im OSM-Kontext erhalten, da man dann bei einer Parkplatzsuche nicht hunderte straßenbegleitende Stellplätze im Abstand weniger Meter angezeigt bekommt.

Ihr habt euch für einen gewerblichen Usecase eine Wikiseite geschrieben, die eurem kommerziellen Interesse, eurer Arbeitsweise und Auswertung/Präsentation entspricht und setzt jetzt dieses Schema mittels bezahlter Mapper als Quasistandard durch. Gegenüber Kritikern/Freizeitmappern verweist ihr dann auf den “gängigen” Standard - den ihr selbst erschaffen habt. Den Kommunen verkauft ihr das ganze dann noch mit dem OSM-Label als “Opendata” und “Communitybasiert” …

Zu Berlin: Du sagst selbst, dass ihr über das Ziel hinausgeschossen seit. Was folgt daraus? Räumt ihr das dann auch wieder auf und korrigiert die fehlerhaften Einträge? Ich sehe das nämlich nicht.

Aber das ist ja auch logisch: Wenn das bezahlte Projekt abgeschlossen ist, die Projektergebnisse dem Auftraggeber präsentiert wurden und die Rechnung bezahlt wurde, dann zieht man ja auch weiter in die nächste Kommune und verkauft sein Produkt an den nächsten Auftraggeber. Jetzt hat man ja auch ein Referenzprojekt, auf das man verweisen kann und so zieht man von einem zum nächsten Ort …

Die Freizeitmapper räumen dann schon wieder auf und korrigieren “Parkplätze” in Spielstraßen, Wendehammern, usw.

Auf der Wiki-Seite zu amenity=parking_space steht aber auch als erster Punkt im Abschnitt „How to map“:

Start from usual amenity=parking mapping

und weiter unten im Abschnitt „When not to use amenity=parking_space“:

Note that amenity=parking_space should not be mapped instead of amenity=parking but inside of an amenity=parking.

Ich hoffe nicht, weil gerade in Verkehrsberuhigten Bereichen nur auf gekennzeichneten Parkplätzen geparkt werden darf und daher gerade dort eine genaue Erfassung der Stellflächen wichtig ist. Ich wohne in einer “Spielstraße” und normalerweise sind hier auf dem Land Parkplätze kein Problem, wie in den ganzen 30-Zonen. Hier in unserer Straße aber schon. Wenn man Besuch bekommt, muss dieser immer außerhalb parken und darf dann hierher latschen.

Das solltest du den Apps vorwerfen und nicht einem Mapper, der richtige Daten nach dem aktuellen Standard einträgt.

Parkplatzsuche im realen Leben kann kompliziert sein, wenn es Parkplätze und Parkstreifen gibt. Eine App kann entweder Informationen (zB street side Stellplätze) weglassen, damit es übersichtlicher wird, oder sie zeigt dir alle Details, aber dann halt so unübersichtlich wie es auf der Straße eben ist.

Ich finde, es wäre schlechter, wenn die Arbeit von @Supaplex030 abseits von OSM gemacht werden würde. Ich finde es ein tolles Projekt. Wenn andere Kommunen folgen, wird unsere Datenbank immer besser.

in Wendehämmern darf man grundsätzlich parken, nur wenn es ausdrücklich verboten ist oder der Platz nicht reicht darf man nicht. In verkehrsberuhigten Bereichen sieht es anders aus, da darf man nur in explizit markierten Flächen parken. Hast du mal ein paar Beispiele wo Parken gemappt wurde aber nicht erlaubt war?