Closed tordans closed 1 year ago
Am Ende sollten wir ohnehin alle Stücke ausschließen, die zu kurz für ein Fahrzeug sind. Das wäre hier der Fall. Möglicherweise müssen wir vorher das "merging"/Verschmelzen von Parkstreifen mit gleichen Eigenschaften optimieren.
logisch gesehen weiß osm nicht, dass dort eine kreuzung ist, oder? ansonsten muss man sich das irgendwie aus den daten dazu dichten.
also abstand zwischen kreuzungspunkten zu eng, also mit oneway separat gemapte fahrtrichtungen, ohne einbahnstraßenschild (sonst dürfte man ja innen am bordstein parken).
wenn ein bordstein gemapt wäre, kann man den abstand dazu ermitteln, der fehlt im kreuzungsbereich, also kann man dort nicht parken. genauso sollte ein separater fußweg nicht mit footway=sidewalk sondern footway=crossing sein, also ist es eine kreuzung, also darf man nicht parken
Im Script werden die Bordsteinschnittpunkte aus der (interpolierten) Straßenbreite interpoliert. Um Umkreis von 5 Metern um so einen Schnittpunkt wird alles abgeschnitten. Es wäre zusätzlich möglich, "virtuelle Kreuzungsflächen" aus den Flächen der Straßen selbst zu interpolieren. In meinem Neukölln-Prototyp hätte das aber nur vereinzelt einen Mehrwert gebracht.
Zusätzlich könnten wir auch Segmente innerhalb von in OSM separat gemappten Knotenpunktflächen (area:highway=*
+ junction=yes
) ausschließen, aber sowas gibt es bisher nur sehr selten.
Ich fürchte das Problem ist doch etwas aufwendiger zu lösen. Auch ich denke in die Richtung eine "Kreuzungsfläche" zu erzeugen und habe schon Experimente gemacht. Bisher habe ich versucht, nach dem Berechnen und Versetzen der parking_lanes, die Schnipsel zu entfernen. Aber so eine Kreuzung kann recht komplex sein.
Inzwischen denke ich, die Straßenlinie (highway=*) bei Kreuzungen zuerst zu kürzen und dann alle Berechnungen und weitere Verschneidungen zu machen. Schnipsel mit einer Länge <1.7m werden bereits entfernt.
Ein Beispiel einer Kreuzung
Das mit dem "Vor-Kürzen" ist eine gute Idee. Das würde das Problem hier und an ähnlichen Stellen lösen. Bei Kreuzungen mit scharfen Winkeln und breiten Straßen könnten dadurch aber evtl. neue Fehler entstehen. Müssten wir mal prüfen, welche Variante die "weniger schlimme ist" :)
Ein Ausschluss im Kreuzungsbereich - entweder über den orangenen Kreis (Durchmesser = schmalste zulaufende Straßenbreite) oder eine virtuelle Kreuzungsfläche entsprechend der zulaufenden Straßenbreiten) ist darüber hinaus nützlich, denke ich. Wenn alle Segmente mit capacity < 1 entfernt werden (statt pauschal nach Länge zu gehen), dürfte das Problem eigentlich auch weitgehend gelöst sein, oder? (In meinem Phython-Prototyp-Script gehe ich afaik so vor und habe kaum Probleme mit den Artefakten). Sehr seltenen Ausnahmen könnten beim Querparken entstehen, wo bereits ein 1,8-Meter-breites Segment eine capacity von 1 aufweist.
Vielen Dank! Klar wenn es keine capacity gibt, braucht es auch nicht angezeigt werden. Ich habe mir mal alle mit capacity = NULL eingeblendet und Stichproben gemacht. Die können wirklich ausgefiltert werden.
Ich benutze nun gekürzte highways. Es wird ein 5m-Puffer um jede highway-Kreuzung erzeugt und die highway-Linien darin ausgestanzt.
Das funktioniert gut bei einer Kreuzung mit 4 Segmenten. Bei einer "T-Kreuzung" mit 3 Segmenten, sollten nicht alle Segmente gekürzt werden.
Außerdem gibt es immer noch Artefakte hier oder
hier. Hier ist also noch weitere Arbeit notwendig.
In der Seelingstraße in Charlottenburg befinden sich auch noch zwei, wobei die capacity als 16 angezeigt wird. Liegt vermutlich auch an der Ausstanzung?
Ich habe gerade nochmal nachgeschaut, wie das Ausschneiden der Artefakte in Kreuzungsbereichen im Pythonscript gelöst ist und da gibt es zwei Varianten (Zeile 1970 ff.):
Lars hat die letzten Tage einiges verbessert. Ich habe mir meinen Case(i~parkingPoints~a~_F~s~!(i~default~a))(i~parkingAreas~as~!(i~default~a)(i~position-separate~a~_F))(i~parkingDebug~a~_F~s~!(i~default~a))(i~parkingStats~a~_F~s~!(i~default~afilters~!(i~admin_level~o~!(i~4~a~_F)(i~9~a)(i~10~a~_F)))(i~length~a~_F~filters~!(i~admin_level~o~!(i~4~a~_F)(i~9~a)(i~10~a~_F))))(i~landuse~a~_F~s~!(i~default~a))(i~mapillaryCoverage~a~_F~s~!(i~default~a)))~) nochmal angeschaut und das sieht jetzt super aus.
Ich schließe das Ticket jetzt hier; bitte macht ein neues Ticket auf, wenn euch wieder etwas auffällt.
Beispiel: http://localhost:3000/project-vector-tiles#17.93/52.4813/13.437814
Die kleinen Stücke in der Mitte sollten wir irgendwann noch bereinigen.