No support for "transition" placement value

[MTRNord]

https://github.com/SupaplexOSM/strassenraumkarte-neukoelln/blob/d22c129f8c1ebc044716713d4cc16e0cae98da18/mapstyle/post_processing.py#L631

Hi I wanted to try this with kiel which uses the "transition" value for the placement key a lot. This fails in line 657 with ValueError: invalid literal for int() with base 10: 'n'

[MTRNord]

For reference: https://wiki.openstreetmap.org/wiki/Tag:placement%3Dtransition

[tordans]

Ich habe mal etwas mit Overpass die Daten in Kiel angeschaut. Für mich sieht die Fehlermeldung danach aus, dass im Code etwas nicht abgesichert ist gegen Tagging-Formate die unerwartet oder falsch sind.
https://overpass-turbo.eu/s/1BDW

Ich habe die Vermutung, dass im Code immer einfach das letzte Zeichen des Tags verwendet wird, was eine Zahl sein müsste nämlich =<EinstelligeZahl> aber das irgendwo bei euch dann stattdessen transition da steht, wo eine Zahl erwartet wird.

Aber im Detail kenne ich weder Code noch Tagging genug, um mehr sagen zu können.

[MTRNord]

Ah das kann auch sein. Ich dachte transition darf in allen "placement" keys stehen 🤔. Das kann natürlich auch falsch sein in den osm daten.

[MTRNord]

Hm wobei alle "transition" values sind im placement key und nicht in einem der anderen placement keys. Sollte also so stimmen.

[tordans]

Dann weiß hoffentlich @SupaplexOSM wie man das besser debuggen kann. Zum Beispiel wäre die OSM ID von dem Weg der den Fehler erzeugt ja praktisch…

[SupaplexOSM]

placement=transition ist korrekt und kommt auch in Neukölln häufiger vor. Sollte also eigentlich nicht das Problem sein, da es im Script speziell behandelt wird... Andererseits deutet die Fehlermeldung darauf hin, das es mit einem "n" als letztem Zeichen zu tun hat und in den OSM-Daten in Kiel entdecke ich keine Fehler... Merkwürdig.

Tatsächlich ist der Code an den meisten Stellen nicht wirklich gegen ungültige Tags abgehangen (oder nur dann, wenn ich auch mal auf solche Daten gestoßen bin). Ich habe mir meistens damit beholfen, wie @tordans bereits schrieb, die aktuelle Way-ID auszugeben und mir dann die Segmente anzuschauen, an denen das Script crasht.

Bekommst du noch mehr Fehlerzeilen außer diese eine, um z.B. zu sehen, aus welcher Zeile die "getAbsolutePlacement"-Funktion aufgerufen wird? Es gibt mehrere Möglichkeiten und die Funktion selbst kennt die Geometrie nicht (und kann daher keine ID ausspucken).

Du könntest ansonsten auch mal versuchen, einfach vor jede Zeile, die "getAbsolutePlacement" aufruft, ein print(lane.attribute('id')) zu schreiben – das spült zwar die Ausgabe mit vielen Log-Meldungen zu, aber wenn der Fehler auftritt, müsste die letzte Ausgabe das verursachende Wegsegment enthalten.

[SupaplexOSM]

Achso, nagut, was mir auffällt: placement sollte nach meinem Verständnis (und dem Proposal) an Straßen mit Zweirichtungsverkehr (also ohne oneway) mit :forward oder :backward genutzt werden, damit klar ist, auf welche Richtung sich die Angabe bezieht. In Kiel gibt es ein paar Wegstücke, wo es nicht so gemacht ist. Könnte was damit zu tun haben... In Neukölln gibt es zwar auch ein Wegstück, an dem das nicht der Fall ist, aber vielleicht geht es da zufällig gut – falls es was damit zu tun hat.