Berechnet man die Route von 50.2198,10.2899 (Weichtungen) nach 50.2378,10.2732 (Wermerichshausen), gibt es so eine komische Ausbuchtung.
Etwas damit rumgespielt, schließlich stellte sich heraus:
Nimmt man nicht Car.Fastest(), sondern Car.Shortest(), verschwindet das Problem.
Berechnet man die umgekehrte Route, verschwindet das Problem ebenfalls.
Daraufhin bei OSM in die Rohdaten gesehen. Und ein Objekt “Gras” gefunden.
Das sollte wohl neben der rechten Straßenseite liegen. Es liegt aber teilweise auf der Fahrspur in Richtung Wermerichshausen.
Das sieht so aus, als ob der Nutzer Daten von Maxar übernommen hat, dabei aber so ungenau war, daß das für manche Routing-Programme zum Problem werden kann.
Valhalla, OSRM, Graphhopper und Brouter haben damit kein Problem.
Die Kreisstraße selber hat mit ‘gras’ nichts am Hut und auch keine gemeinsamen Nodes oder sonst was mit der Fläche. Lediglich die Fläche schneidet sich virtuell (d.h. was die Koordinaten angeht) mit der Straße.
Wenn das wirklich der Grund sein sollte, dann gute Nacht für Iterno. Das wirst du in OSM massenhaft sehen.
Du wirst auch sehen, dass eine Straße gemeinsame Nodes mit einer angrenzenden Fläche hat.
Da waren dann “Kartenmaler” am Werk, die die Grasfläche gerne bis in die Mitte der Straße ziehen, weil ja sonst eine farbliche Lücke sichtbar sein könnte.
Kann gerne korrigiert werden, wenn du viel Zeit hast.
Iterno sollte sich abgewöhnen, solche Flächen zu berücksichtigen und ausschließlich “surface” , “tracktype”, … der Straße zu nehmen - sofern gemapped (anderfalls ‘defaults’).
OsmAnd hat ebenfalls keine Probleme mit dem Routing am genannten Bereich.
Allerdings ist das tatsächlich nicht “schön” so wie es eingetragen ist, was wie oben angemerkt häufig vorkommt.
Das war die Itinero-Version 1.5.1, die letzte stabile mit einer RouterDb vom 18.10, bei der AddContracted(“Car”) etwa eine Stunde gedauert hat.
Heute nachmittag die noch per Preview markierte Version 1.6.0-pre36 eingespielt, damit tauchte das Problem ebenfalls auf.
Begonnen, die aktuelle RouterDb zu laden. Da dauerte das Erstellen von AddContracted(“Car”) über 5 Stunden für ganz DE, war erst vorhin fertig.
Damit - verschwand grade das Problem.
Bei Github hat jemand analog berichtet, daß es ab der pre32 - Version extrem lange dauern würde, bis AddContracted erstellt wurde.
Das braucht man aber, da sonst die Performance eine Katastrophe ist.
Sprich: Es war wohl eher so etwas wie ein internes Datenproblem von Itinero, das zu der Fehlberechnung geführt hat.
Trotzdem gut: Nun weiß ich, daß solche “grass” - Elemente für Routing-Software kein Problem sein sollten. Verblüffend war, daß das Problem nur in einer Richtung aufgetreten war.
