Processing: Merge segments before calculation

[tordans]

Location

This looks like a nice edge case:
The OSM way that the "Missing data" Segment belongs to is https://www.openstreetmap.org/way/1133008268. This one gets split by the driveway.

The left over piece is too small for processing. However, we should in fact merge it first with the line next to it which has the same parking tags. Together they would likely have space for 1 more car…

[SupaplexOSM]

Ja, das sollten wir auf jeden Fall tun. Das ist eigentlich kein Edge Case, weil diese Art von Fehler jederzeit passiert, wenn sich Attribute der Straße oder einer Parkstreifenseite ändern, was bei detailliert erfassten Daten oft der Fall ist (etwas weiter südlich z.B. auf der Flughafenstraße gibt es auch viele kurze Segmente nebeneinander, obwohl einige davon zusammengehören, weil mal auf der einen, mal auf der anderen Seite die Parkbeschränkungen wechseln).

Das Pythonscript "dissolved" einfach gleich zu Beginn alle Parksegmente mit gleichen Attributen (nach dem sie auf die rechte und linke Seite aufgeteilt wurden), wodurch aneinander grenzende "gleiche" Segmente verschmelzen (siehe Zeile 1879ff.) – funktioniert gut.

Es gibt im Pythonscript allerdings noch einen Edge Case, der momentan nicht abgefangen wird: Die verschmelzenden/benachbarten Segmente sollten in die gleiche Richtung zeigen, sonst könnten theoretisch Parkstreifen gemerged werden, die gar nicht zusammengehören, wodurch ein fehlerhafter "Tausch" der Eigenschaften an einem der Parkstreifen entsteht. Irgendwo im Schillerkiez gibt es eine Stelle, wo das passiert (zwei an der gleichen Kreuzung startende, aber in verschiedene Richtungen zeigende Linien, die jeweils auf der linken und rechten Seite die gleichen Parkattribute haben – was sich durch die verdrehte Richtung in der Realität aber auf verschiedene Straßenseiten bezieht). Kann aber auch sein, dass das mit der SQL-Methode kein Problem wäre, weil die Straßenseite als Attribut bekannt ist.