Parkplatz-Micromapping

n abend, das hier sieht aus wie ein Rekordversuch: die Stadt mit der höchsten Parkplatzdichte Deutschlands.

Ich hab in Changeset: 129945538 | OpenStreetMap schon was dazu geschrieben, keine Reaktion.

In dem jetzigen Zustand finde ich das alles andere als brauchbar. Sollte man da den P-Wald abholzen? Ich tu mich immer schwer, Arbeit von anderen wegzuschmeißen.

4 Likes

Also ich find’ das gut, das jemand sowas einträgt. Zumindest, solange da wirklich Parkplätze sind. Letzten Endes zeigt das doch auch, wie viel Platz wir für Autos verwenden…

Warum?

9 Likes

Ja! Abholzen!

3 Likes

Ich kann jetzt nichts “unbrauchbares” entdecken. Viele private Parkplätze sind aber wohl dabei.

Ein paar Parkflächen stammen auch von mir. Auch da hat jemand noch sehr viel Arbeit und Detail hinzugefügt, teils ist jede Parkfläche, jede E-Ladestation etc. erfasst worden.

1 Like

Ich fände die Verwendung dieses Schemas für ein solches Detailmapping besser:
Street parking - OpenStreetMap Wiki

So kann man auch (ja, auch der Renderer) besser zwischen “richtigen” Parkplätzen und einfachen Parkmöglichkeiten am Straßenrand unterschieden werden.

5 Likes

In OSM-Carto gibt es meine ich ein Bestreben, Parkplätze mit kleineren Grundflächen insgesamt unauffälliger zu rendern, insbesondere natürlich das große “P”. Habe auch schon gesehen, dass das erfolgt. Nur - manchmal klappt es, manchmal aber auch nicht. Ich habe absolut keine Ahnung woran das liegt, mglw. hängt es mit der Geometrie der parking-Fläche zusammen.

Das soll nur am Rande erwähnt sein.

OSM als verkehrspolitisches Propagandainstrument? Bitte nicht. Im Übrigen ändert es nichts am Flächenverbrauch, ob man am Straßenrand parken darf oder nicht.

Punkt 1: ich will damit nicht sagen, dass die Daten vollkommen nutzlos sind. Hab ich auch nicht gesagt. Deshalb will ich sie ja nicht einfach wegwerfen.

Punkt 2: Ich will sagen, dass ich die Daten so nicht hilfreich finde. Das hab ich im oben verlinkten CS schon erklärt, hast du möglicherweise nicht gelesen. Also nochmal: Wenn ich in eine mir fremde Stadt komme und einen Fleck suche, wo ich zwecks Stadtbummel und Mittagessen mein Auto hinstellen kann, bevor ich beim Kunden eintreffe (nein, 300 km mit großem technischem Equipment ist weder zu Fuß noch mit der Bahn vernünftig machbar), dann nützt es mir nichts, wenn mir zwar Hunderte von Parkplätzen im Navi angezeigt werden, ich aber keinen davon benutzen kann, weil das entweder besetzte Straßenrandparklücken sind oder Stellplätze auf privaten Grundstücken. amenity=parking sind für mich ausgewiesene Stellflächen für Fahrzeuge, mit einem P beschildert. Nicht jede kleine Abstellmöglichkeit von ein paar Quadratmetern.

Damit diese Parkplatzerfassung nützlich wird, brauchts zumindest im Tagging eine Unterscheidung von “richtigen” ausgewiesenen Parkplätzen und schlichten Abstellmöglichkeiten für je ein Fahrzeug ohne spezielle Widmung. Dass für straßenbegleitendes Parken sowieso ein anderes Erfassungsschema gedacht ist, wurde ja schon wiederholt angesprochen.

2 Likes

Ein großer Teil der Parkplätze dort müsste parking=street_side bekommen. Dann wird übrigens auch das P auf der Karte kleiner.

10 Likes

Wie wäre es denn wenn man für Stellplätze einfach nur
amenity=parking_space
verwendet anstatt amenity=parking. Dann sind auch die P aus der Karte weg.

Nicht gut. Laut der verlinkten Wikiseite sind das die einzelnen Stellplätze innerhalb eines großen Parkplatzes. Wie Parken am Straßenrand gemappt wird, steht in DE:Street Parking.

3 Likes

Da fehlen einfach access-Tags. private, customers und evtl. noch ein paar andere werden deutlich unauffälliger gerendert.

Dann sollte man da noch mal Nachbessern. Eine Stellfläche im Straßenraum ist noch lange kein “Parkplatz”. (Der zugehörige “Parkplatz” ist die Straße.) Auch wenn wir das manchmal gleich nennen (Ich suche einen Parkplatz), sind das aus meiner Sicht zwei verschiedene Dinge und das zeigt ja auch die Existenz dieser Diskussion.

Man muss dem Renderer irgendwie helfen, zwischen Stellfächen am Fahrbahnrand und separaten Parklätzen zu unterscheiden.

Edit. Ist ja mit parking=street_side bereits gegeben.

1 Like

Ist so aber dokumentiert und halte ich für richtig und sinnvoll:

In case you want to map street parking separately with its own geometry (e.g. a street-side parking bay), draw an area of the size of the parking facility and add amenity=parking + parking=* (e.g. parking=street_side).

Wenn man lediglich auf der regulären Fahrbahnbahn parken darf, dann aber nicht. Wurde das hier gemacht?

Wichtig ist, dass man solche Flächen mit parking=street_side entsprechend markiert, damit diese von einem eigenständigen Parkplatz unterscheiden kann.

1 Like

Im Sateliten-Bild sieht man, dass es sich (an vielen Stellen) um Parkplätze auf der Fahrbahn handelt, die aber von der Gemeinde als solche markiert wurden (weiße Streifen, davor und danach Zickzack). Meiner Meinung nach ist das genau der Anwendungsfall von parking=street_side. (Stellen, an denen man auf Grund von rechtlichen Regelungen am Fahrbahnrand parken darf, ohne das dort Markierungen sind, würde ich auch nicht gemappt haben wollen.)

2 Likes

Eine reine farbliche Markierung macht daraus aber kein street_side-Parken.

Von daher: Ja, ein paar sind street_side, aber das Gros ist eigentlich parking=lane und das separat zu mappen mit amenity=parking finde ich gewagt.

4 Likes

Ist aber tatsächlich auch so definiert:

How to map

Draw the area where the cars can park, and tag it with amenity=parking and parking=lane.

https://wiki.openstreetmap.org/wiki/Tag:parking%3Dlane

amenity=parking + parking=lane gibt es auch bereits > 53.000 mal.

Das sollte voraussetzen, dass die Fahrbahn auch flächenhaft erfasst ist. Anders macht das topologisch keinen Sinn.

Das sieht übrigens aus wie Parkflächen neben der Straße.
image

Edit: “weil” war hier fehlt am Platze. Das falsche Kartenbild sollte nicht das Hauptargument gegen diese Art von Mapping sein.

1 Like

Für mich macht das separate Erfassen von parking=lane überhaupt nur Sinn, wenn es spezielle Einzelparkplätze, z.B. mit Ausweisnummer XY sind. So, wie es hier im Beispiel genutzt wurde, ist es komplett unsinnig. Ich würde also sagen: kann man so machen, solte aber nicht die Regel sein.

1 Like

Wir mappen nicht für den Renderer sondern erfassen Geo-Daten. Und da ist eine Flächenerfassung immer besser weil sie mehr Informationen enthält. Ein Renderer muss diese Flächen nicht darstellen, wenn es aus Kartensicht keinen Sinn macht.

7 Likes

Zur richtigen Erfassung gehört aber auch korrekte Topologie. (die Verbindungen zwischen den Objekten)

Dort wo es notwendig ist, sollte ich nicht Dinge die aufeinander liegen, nebeneinander Zeichnen. Das trifft insbesondere auf flächenhaft erfasste Objekte zu. Es ist eine äußerst merkwürdige Modellierung wenn das große Hauptobjekt “Fahrbahn” zu einer Linie vereinfacht ist, das viel kleine Objekt “beparkte Fläche” in der Fahrbahn aber als Fläche erfasst wird.

Edit: Straße → Fahrbahn verbessert.

1 Like