osm-parking-processing icon indicating copy to clipboard operation
osm-parking-processing copied to clipboard

Published 20 hours ago • verified publisher icon osmberlin

`highway=construction + !parking:lane` ausschließen

Open tordans opened this issue 3 years ago • 7 comments

Das Skript berücksichtigt zur Zeit alle highway=construction gleich; auch solche, die mit construction=footway getaggt sind.

  • Beispiel: https://www.openstreetmap.org/way/1008970410

Das führt zu falschen Darstellungen.

Es könnte aber auch sein, dass es highway=construction gibt, die bereits parking:lane=* Informationen haben. Diese sollten wir weiter einschließen und jede andere Straße behandeln.

Ich sehe diese Optionen:

  • highway=construction + construction=footway|path|track|(was noch?) ausschließen
  • highway=construction nur einschließen, wenn auch ein parking:lane=* vorhanden ist (egal ob no oder andere Daten)

tordans avatar Apr 29 '22 15:04 tordans

Ich wäre dafür highway=construction komplett zu ignorieren. Solange es eine Baustelle ist, ist die Straße nicht oder nur eingeschränkt für den Verkehr (fahren, parken) nutzbar. Wenn bereits parking-Tags vorhanden sind, werden sie berücksichtigt, sobald das construction wegfällt.

Wenn ich das Query richtig habe, gibt es in Berlin nur einen Fall: https://overpass-turbo.eu/s/1i3E

gislars avatar Apr 29 '22 17:04 gislars

Ich würde highway=construction genau wie die anderen highway-Straßenkategorien behandeln, wenn der construction-Subtag ausdrückt, dass es sich um eine Straße handelt (highway=construction + construction=primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|residential|unclassified|living_street|pedestrian|road).

Anwender dürften sich üblicherweise nicht dafür interessieren, ob gerade irgendwo eine Baustelle ist oder nicht und sie würden dann unnötigerweise Daten verlieren, wenn sie z.B. eine Kiezauswertung, eine Szeario-Rechnung o.ä. machen.

SupaplexOSM avatar Jun 25 '22 12:06 SupaplexOSM

Bei Baustellen habe ich die beiden Beispiele Karl-Marx-Straße und Ganghoferstr vor Augen. Bei letzterer ist die Baustelle zusätzlich gemappt, der Vorher-Zustand existiert parallel. Deswegen funktioniert hier die Berechnung. Bei der KMS hat sich der Straßenverlauf geändert, den Vorher-Zustand gibt es nicht mehr.

Was mMn gegen die Auswertung von highway=construction spricht:

  • in einer Baustelle ist Parken nicht erlaubt, die Baustelle kann sogar für den Verkehr gesperrt sein
  • sonst gültige Regeln (z.B. 5m-Kreuzungs-Abstand) gelten in Baustellen nicht, die verlegte Straße könnte sogar über einen Fußweg führen
  • die Parkplatzsituation während der Baustelle und nach Fertigstellung kann sehr unterschiedlich sein

gislars avatar Jun 25 '22 14:06 gislars

Ok, ich denke eher an kleine temporäre Baustellen, die in OSM ja auch öfter mal gemappt werden. Aber vielleicht hast du recht und die "größeren" überwiegen. Müsste ich mal genauer evaluieren.

SupaplexOSM avatar Jun 25 '22 16:06 SupaplexOSM

Meine Sicht der Dinge – und ich sehe die noch nicht entkräftet durch die Beispiele.

  • Wir haben eine Straßen-Defintion <LISTE>, die wir verwenden.
  • Wenn highway=construction + construction=<LISTE>, dann werden wir das so aus, als wäre das eine Straße vom Typ <Liste>. Warum: Weil die Baustelle immer temporär ist; wenn auch mal 2 Jahre. Und wenn es mal edge cases gibt, muss man halt die Parkspur-Tags von der Baustellen-Straße wegnehmen. Das ist ja auch "richtig", sogar "richtiger", denn "on the ground" gibt es keine Parkspur mehr. Aber wir sparen uns das in OSM meist, weil es die Wartung vereinfacht (AKA das "zurück-mappen zur Straßen nach Baustellen-Ende").

Was mMn gegen die Auswertung von highway=construction spricht:

  • in einer Baustelle ist Parken nicht erlaubt, die Baustelle kann sogar für den Verkehr gesperrt sein
  • sonst gültige Regeln (z.B. 5m-Kreuzungs-Abstand) gelten in Baustellen nicht, die verlegte Straße könnte sogar über einen Fußweg führen
  • die Parkplatzsituation während der Baustelle und nach Fertigstellung kann sehr unterschiedlich sein

Ich stimme dem letzten Argument voll zu! Aber das muss dann danach oder sobald es bekannt wird gemapped werden. Die anderen Argumente gelten für mich nicht, weil wir ja keinen Router oder keine Karte zur Orientierung bauen, sondern einen klaren Fokus auf Parkstände haben. Und solange die Daten gemapped sind, sollten wir sie anzeigen. Wenn jemand schon weiß, dass sich Dinge verändern werden, kann man die Tags ja auch ändern …

Die Beispiele

Karl-Marx-Straße ==> Kein Problem

  • Die ist ist immer schon zwei-spurig gemapped. Eine Spur ist als Baustelle blockiert, die andere frei.
  • Wir würden für beide die Parkstände angeben, solange sie bekannt sind.
    • Nach Süden sind keine gemapped https://www.openstreetmap.org/way/29328289#map=19/52.48268/13.43267
    • Nach Norden schon, https://www.openstreetmap.org/way/764003856, das ist ein ganz normaler Fall

Sprich, hier gibt es IMO kein Problem, wenn wir construction wie definiert berücksichtigen.

Donaustraße ==> Kein Problem

  • Der "Bug", den wir hatten, lag daran, dass wir nicht auf construction=<LISTE> geprüft hatten. Daher sind in den Daten die Segmente highway=construction + construction=footway aufgetaucht.
    • https://www.openstreetmap.org/way/1008970410#map=19/52.47970/13.44005
    • https://www.openstreetmap.org/way/970452276

Sprich, hier gibt es IMO kein Problem, wenn wir construction wie definiert berücksichtigen.

Hinweis: Aktuell ist es unter https://parkraum.osm-verkehrswende.org/project-vector-tiles/#17.51/52.479556/13.439751 in den Daten ja richtig.

Beispiel Weserstraße

Die Weserstraße sollte IMO weiterhin berechnet werden (wird es in den aktuellen Live-Daten auch)

  • https://www.openstreetmap.org/way/1050315263#map=18/52.48569/13.43661
  • https://parkraum.osm-verkehrswende.org/project-vector-tiles/#17.39/52.485629/13.436441

Weitere Fälle finden…

https://overpass-turbo.eu/s/1jDV

Wie wir damit umgehen sollte IMO

  • Wie oben beschrieben berücksichtigen
  • In den Daten aber schreiben highway=<WertVonConstruction>
  • Zusätzlich in den Daten ein Feld machen, dass das Segment als Construction markiert, vielleicht mit einem Access access=no @ construction (oder sowas ähnlichen), damit man beim Auswerten sehen kann, dass dieses Segment zur Zeit nicht zugänglich ist.

tordans avatar Jun 25 '22 18:06 tordans

https://www.openstreetmap.org/way/4902510 hab ich auch noch nicht geändert, auch wenn das vor ort schon jetzt anders aussieht als in osm damals. die neuen parkplätze sind parallel, nciht diagonal, also sind es weniger, auch der gehweg wird wohl breiter, derzeit aber teils gesperrt etc. und genau - ich bin zu faul das immer wieder im verlauf der baustelle hin und her zu mappen. wenn die baustelle fertig ist (für den abschnitt, danach kommt noch ein zweiter) ändere ich das zum neuen zustand.

joshinils avatar Jun 27 '22 06:06 joshinils

ich seh grad, dass construction=motorway|motorway_link oder service (noch) beachtet wird, also als blau #99a4f1 dargestellt; https://www.openstreetmap.org/way/801304797 https://www.openstreetmap.org/way/430595488 https://parkraum.osm-verkehrswende.org/project-vector-tiles/#17.34/52.472363/13.461407

joshinils avatar Jul 19 '22 05:07 joshinils