Open tordans opened 2 years ago
gislars
commented
2 years ago 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
SupaplexOSM
commented
2 years ago 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.
gislars
commented
2 years ago 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:
SupaplexOSM
commented
2 years ago 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.
tordans
commented
2 years ago Meine Sicht der Dinge – und ich sehe die noch nicht entkräftet durch die Beispiele.
<LISTE>, die wir verwenden.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 …
Karl-Marx-Straße ==> Kein Problem
Sprich, hier gibt es IMO kein Problem, wenn wir construction wie definiert berücksichtigen.
Donaustraße ==> Kein Problem
construction=<LISTE> geprüft hatten. Daher sind in den Daten die Segmente highway=construction + construction=footway aufgetaucht.
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)
Weitere Fälle finden…
https://overpass-turbo.eu/s/1jDV
highway=<WertVonConstruction>access=no @ construction (oder sowas ähnlichen), damit man beim Auswerten sehen kann, dass dieses Segment zur Zeit nicht zugänglich ist.
joshinils
commented
2 years ago 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
commented
2 years ago 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
Das Skript berücksichtigt zur Zeit alle
highway=constructiongleich; auch solche, die mitconstruction=footwaygetaggt sind.Das führt zu falschen Darstellungen.
Es könnte aber auch sein, dass es
highway=constructiongibt, die bereitsparking: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ßenhighway=constructionnur einschließen, wenn auch einparking:lane=*vorhanden ist (egal obnooder andere Daten)