Closed joshinils closed 1 year ago
Ich mappe in verkehrsberuhigten Bereichen immer schlicht parking:lane:<side>=no
, wenn nichts markiert ist. parking:condition:<side>=no_parking / no_stopping
benutze ich nur, wenn Park- bzw. Halteverbote explizit ausgeschildert sind - dann kann man solche expliziten Verbote nämlich aus den Daten eindeutig ableiten. (Ja, man könnte annehmen, das das Spielstraßenschild ebenso als Verbot behandelt werden kann wie ein Halte-/Parkverbotszeichen, aber das wird mMn bereits durch das living_street an der Straßenlinie ausgedrückt und ist daher quasi implizit statt explizit. Ist wohl geschmackssache bzw. nicht klar definiert...)
Wenn es in Spielstraßen Markierungen gibt, sind die zum Glück meistens "parkstreifenartig", dann geht parking:lane:<side>=<orientation>
. Die Values marked
und painted_area_only
haben sich mir noch nie so richtig erschlossen bzw. versuche ich zu vermeiden, da sie in keiner Weise auswertbar bzw. sinnvoll interpretierbar sind (solange man diese nicht separat mappt, was dann wiederum separate
an der Straßenlinie bedeuten würde).
Dennoch kann es Fälle geben, in denen marked
oder painted_area_only
gemappt sind - hat jemand eine Idee, wie wir dann damit umgehen sollten/wie wir das interpretieren? Ich bin da eher ratlos.
Edit: Wenn eine capacity
getaggt ist, kann man die natürlich entlang des Segments verteilen, aber capacity
an Straßenlinien ist eigentlich nicht empfehlenswert zu mappen, da die Linie später verändert/zerschnitten/vereinigt werden könnte und die Gefahr groß ist, das dabei nicht auf capacity-Werte geachtet wird, die dann falsch werden.
Ja, man könnte annehmen, das das Spielstraßenschild ebenso als Verbot behandelt werden kann wie ein Halte-/Parkverbotszeichen, aber das wird mMn bereits durch das living_street an der Straßenlinie ausgedrückt und ist daher quasi implizit statt explizit. Ist wohl geschmackssache bzw. nicht klar definiert...
ja genau das meine ich, dort kann man für die analyse annehmen, dass man nirgends parken darf, als standardwert. das scheint derzeit nicht der fall zu sein.
zumnindest kann man das unterscheiden zu explizit angegeben, oder implizit durch den straßen-tag
Ach so meinst du das. Ich würde auf keinen Fall mit defaults arbeiten: Habe mir die living_streets in Neukölln und Umgebung mal angesehen und in den meisten sind Parkbereiche ausgewiesen.
Ich schließe hier mal, da wir im Projekt eher darauf verzichten wollten, implizite Annahmen zu treffen (und wir gerade Tickets aufräumen ;). Also wenn für einen verkehrsberuhigten Bereich keine Daten erhoben wurden, dann sollte das so auch im Tool erkennbar sein, um sie ggf. zu ergänzen oder die explizite Abwesenheit von Parkplätzen zu ergänzen.
naja, so ganz implizit ist das nicht. in der StVO steht nunmal zu VZ 325.1:
4. Wer ein Fahrzeug führt, darf außerhalb der dafür gekennzeichneten Flächen nicht parken, ausgenommen zum Ein- oder Aussteigen und zum Be- oder Entladen.
ich würde dem entnehmen, dass wenn es keine eingetragenen flächen gibt, es immer überall verboten ist in highway=living_street.
Das Zeichen 325.1 ist ein explizites eingeschränktes haltverbotsschild, quasi eine zone.
wenn infos fehlen, darf man dort nicht parken
Ich meine es eher so herum: Nur weil in OSM keine Parkflächen ausgewiesen sind, heißt es nicht, dass dort keine sind (denn wie weiter oben beschrieben: Erfahrungsgemäß sind in vielen Fällen welche vorhanden). Also für ein Projekt wie dieses hier wäre es besser, zu sehen, dass dort noch keine Informationen erfasst sind (egal ob Parken oder kein Parken) und diese Straßen also als "unbekannter Parkstatus" zu kennzeichnen als pauschal von "kein Parken" auszugehen, obwohl es so nicht explizit in den Daten steht.
ja, mit unbekannt geh ich d'accord. das ist ja was anderes als zu sagen da ist eigentlich immer was pauschal gesagt, wäre ja auch eine annahme.
das
highway=living_street
odertrafic_sign=DE:325.1
impliziert (hier wichtig) folgendes: haltverbotparking:condition:<both>=no_parking
mit ausnahme von markierten bereichen;parking:lane:<side>=marked
bzw.parking:lane:<side>:<type>=painted_area_only