Behandlung von Parkflächen

[gislars]

Statt die Straßenlinie zu attribuieren, können die Parkflächen auch als separate Fläche gemappt werden. An der Straßenlinie steht dann z.B. parking:lane:both = separate und die Park-Attribute an der Fläche.

Um diesen Fall zu behandeln gibt es verschiedene Optionen:

• Flächenattribute auf Straßenlinie übertragen, Straßenliniengeometrie ggf. zerschneiden
• Flächenattribute entlang eines Straßensegmentes aggregieren und an das Straßensegment hängen

Beispiel:

• https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=parkingmap#19/52.47687/13.44582 – OSM-Way https://www.openstreetmap.org/way/559505480

[gislars]

Einzeln getaggte Parkflächen (amenity=parking) werden ausgewertet, wenn parking=street_side | lane. Das ist unabhängig davon ob der entsprechende highway-Abschnitt mit parking* = separate getaggt ist. Außerdem werden auch Parkflächen für Fahrräder (amenity=bicycle_parking) ausgewertet.

Es gibt noch Sonderfälle die wahrscheinlich noch behandelt werden müssen. Dazu muss der aktuelle Stand erst reviewed werden.

[SupaplexOSM]

Es gibt Fälle, da sind Parkbuchten sowohl separat als auch an der Straßenlinie gleichzeitig gemappt. Hier in diesem Fall z.B.: https://parkraum.osm-verkehrswende.org/project-vector-tiles/#18.89/52.4880856/13.3971124

Es gibt Abschnitte mit überlappenden Zahlen, aber nur ein recht kurzes Stück. Was passiert hier genau? Und warum hat das lange Segment mit capacity=96 die Farbe, die ansonsten anzeigt, dass Daten fehlen?

[gislars]

Die Farbe der Linie ist blau, weil in der Parkfläche keine "orientierung" getaggt ist. Es steht zwar am highway. Allerdings ist es im Moment so umgesetzt, dass nur die Werte aus der separaten Parkfläche genommen werden.

Die capacity wird aus dem Flächeninhalt abgeleitet.

Das kurze Stücker mit capacity=13 scheint mir ein Fehler zu sein. Den Fall muss ich debuggen.

[gislars]

Das Handling der separaten Parkbuchten muss geändert werden. Ich sammele hier mal meine Pläne/Gedanken

• Erfassung entlang einer Straßenseite unvollständig z.B. nur eine Parkbucht (Beispiel 1)
• nur auf einer Straßenseite wird Parkbucht erfasst, auf der gegenüberliegenden nicht (Beispiel 2, hier ist zwar gerade Baustelle, aber trotzdem gutes Beispiel)
• Parkbucht wird erfasst, aber enthält auch Bereiche in denen nicht geparkt werden kann (Beispiel 3 Schmales Verbindungsstück zwischen den Flächen )

Das wirft die Frage auf, wie die Daten ausgewertet werden können und was als fehlerhaft angesehen wird

pl-Tags vollständig	separate-Tag gesetzt	separate Fläche	pl-Tags von Fläche vollständig	Auswertung	Meldung
erfasst	nicht gesetzt	nicht vorhanden	nein	lane	ok
erfasst	gesetzt	nicht vorhanden	nein	lane	Hinweis ausgeben
erfasst	nicht gesetzt	vorhanden	nein	lane	Hinweis ausgeben
erfasst	nicht gesetzt	vorhanden	ja	lane	Hinweis ausgeben
erfasst	gesetzt	vorhanden	nein	lane	Hinweis ausgeben
erfasst	gesetzt	vorhanden	ja	Fläche	Hinweis ausgeben
nicht erfasst	nicht gesetzt	nicht vorhanden	nein	-	ok
nicht erfasst	gesetzt	nicht vorhanden	nein	-	Hinweis ausgeben
nicht erfasst	nicht gesetzt	vorhanden	nein	-	Hinweis ausgeben
nicht erfasst	nicht gesetzt	vorhanden	ja	Fläche	Hinweis ausgeben
nicht erfasst	gesetzt	vorhanden	nein	-	Hinweis ausgeben
nicht erfasst	gesetzt	vorhanden	ja	Fläche	ok

[SupaplexOSM]

In den letzten vier Zeilen hast du zwei Fälle, in denen zwar eine separate Parkbucht gemappt ist, aber bei "Auswertung" ein "-" steht. Sollte die Parkbucht nicht immer einbezogen werden, egal, ob die Detailinformationen vollständig sind oder nicht? (Der Default wäre dann: Parallelparken auf der gemappten Fläche. Edit: bzw. ich hatte bei mir mal eine Funktion gebaut, die aus der Geometrie der Fläche die Ausrichtung interpoliert. Wenn ich mich richtig erinnere, war das sogar schon recht zuverlässig.)

[gislars]

Wenn nur die Geometrie existiert und keine oder unvollständige parking-Tags vorhanden sind, könnte man mit Default-Werten rechnen.

Das müssen wir festlegen. Ist es ein Mapping-Fehler und wir berechnen nichts, obwohl wir es könnten. Oder sind wir nicht so strickt und berechnen den Wert.

Je nachdem wie wir uns entscheiden, passe ich die Tabelle an. Ich wollte die Fälle mal dokumentiert haben.

[gislars]

Wenn es auf einem Straßenabschnitt eine gemappte Parkfläche gibt, wie soll der Rest der Straße ausgewertet werden.

Beispiel 1 Maybachufer hier sind alle Parkflächen separat gemappt. Zwischen den Parkflächen gibt es logischerweise keine Stellplätze.

Beispiel 2 Gleimstraße hier ist nur ein Teilbereich separat gemappt. Wird für dieses Straßensegment nur das separat gemappte berücksichtigt oder auch der Rest der Linie

Eine Lösung wäre, alle Straßensegmente von der Auswertung ausschließen, denen eine separat gemappte Fläche zugeordnet werden kann. Das kann man auf eine Straßenseite beschränken. Dann wäre bei der Gleimstraße die südliche Seite noch in der Auswertung.

Wenn man hingegen zusätzlich zu den seprat gemappten Flächen auch die restliche Straßenlinie berücksichtigt, dann würde in Abhängigkeit der Mapping-Qualität das Ergebnis zu hoch/niedrig ausfallen.

[SupaplexOSM]

mhm, die Straßensegmente komplett herauszunehmen, denen eine separate Fläche zugeordnet werden kann, könnte auch in "korrekt" gemappten Fällen zu Datenverlusten führen, wenn es kleine Überschneidungen gibt.

Wäre eine Lösung wie die folgende denkbar? Wenn eine Seite eines Straßensegments zu mehr als 50% von einer separaten Fläche "überschrieben" wird, schmeißen wir sie raus, ansonsten bleibt sie an den Stellen drin, an denen keine separaten Flächen sind. Das würde im Fallbeispiel Gleimstraße zum (vermutlich korrekten) Ergebnis führen, dass es östlich die Parkbuchten gäbe, und westlich davon die Parkplätze an der Straßenline.

[SupaplexOSM]

Mir fällt noch ein Anwendungsfall ein, wo das relevant ist: Einzelne "Sonderstellplätze", z.B. Behindertenparkplätze oder Stellplätze an E-Ladesäulen, sollten separat als Nodes oder Flächen gemappt werden können, ohne die Auswertung von parking:lanes rechts und links davon negativ zu beeinflussen. Mit der oben erwähnten 50%-Variante würde im besten Fall im Bereich eines solchen einzelnen Stellplatzes einfach ein kleines Loch in die Parking Lane gestanzt werden, das durch die separate Information gefüllt wird.

[SupaplexOSM]

Nochmal drüber nachgedacht: Vielleicht ist es doch die beste Lösung, sowohl die Infos von der parking:lane als auch der separaten Geometrien gleichzeitig zu behalten, ohne die 50%-Regel. Also dort, wo die Parkbucht ist, werden die parking:lane-Attribute überschrieben, und ansonsten werden sie behalten (so war es doch sogar bisher schon, oder?).

Der Grund: Solche gleichzeitigen Infos sind bisher die einzige Möglichkeit, "doppeltes" Parken auf der Fahrbahn und in Parkbuchten gleichzeitig zu erfassen. Alle Stellen, an denen es solche doppelten Infos gibt, müssen dann also im Debug-Layer hervorgehoben werden als "entweder fehlerhaft gemappt oder gleichzeitiges Fahrbahn- und Parkbuchtparken".