GraphHopper Routing Exception

[thomas.friese]

Eine Frage aus Neugier: Warum hast Du in DownloadableFinder nicht

public Downloadable getDownloadableFor(BoundingBox routeBoundingBox) 

auf eine Liste von Downloadable aufgebohrt?

Weil ich das erst mal als Option neben dran stehen haben wollte (ggf. das als zweite Option sogar konfigurierbar mach).

Man könnte der Methode einen Parameter für die Länge des Resultats zu geben und wenn man sie auf 1 zwingt hat sie quasi deine Signatur und Semantik und die eigentliche Selektion könnte man dann noch von diesem RoutingTileInfo in einen Comparator ziehen, dann sieht man dort wirklich welche Strategie implementiert wird für das Karten-Suchen.

Von der Idee her: was kann da systematisch schief gehen, wenn ich fireDownloading() und downloadAndWait() im Error-Handling für ggf. response Errors in der GraphHopper.getRouteBetween() Funktion aufrufe?

Man erwartet es nicht. GraphHopper#getRouteBetween() sollte keine Fehlerbehandlung und Notifications machen sondern nur ein Routing durchführen.

Schon, aber du hast da ohnehin ein Error-Handling, was eben die Exception weiter wirft, genau an der Stelle muss man ja intervenieren weil der GraphHopper selbst seinen Fehler so signalisiert.

Ich stimme dir gefühlsmäßig vollkommen zu, man müsste eigentlich dann aber vermutlich drumherum noch weitergehend aufräumen und schon in den Interfaces und dem ganzen Flow drumherum diese Möglichkeit vorsehen, dass das Routing schief geht und man es noch mal probieren sollte mit der zweitbesten Karte usw.. Dabei würde man auch die Timer gescheit aufräumen etc. ... für den Proof of Concept hab ich das jetzt nicht gemacht.

Schwierig finde ich

    private List<Downloadable> routingTileInfoList;

Denn eigentlich sollte doch

    private java.io.File osmPbfFile;

auf eine Liste aufgebohrt werden, oder?

Ja, im Prinzip schon, auch hier aber wieder: ich wollte nix aufbohren sondern einen parallelen Pfad einziehen, den ich zum Vergleich an und aus schalten kann - nächster Schritt wäre eh mal einen Test schreiben der bei deinem aktuellen Code mit dem bekannten Fehler failed, mein Code aber erfüllt. Danach würde ich es dann sauber einbauen.
Außerdem hab ich befürchtet, dass du das osmPbFile wie ein Flag verwendest, weil du es mal explizit auf null setzt.

[routeconverter]

Ich stimme dir gefühlsmäßig vollkommen zu, man müsste eigentlich dann aber vermutlich drumherum noch weitergehend aufräumen und schon in den Interfaces und dem ganzen Flow drumherum diese Möglichkeit vorsehen, dass das Routing schief geht und man es noch mal probieren sollte mit der zweitbesten Karte usw.. Dabei würde man auch die Timer gescheit aufräumen etc. ... für den Proof of Concept hab ich das jetzt nicht gemacht.

Der Proof of Concept ist sehr gut. Ich möchte mal schauen, wie man das elegant als Default in den Code hereinbekommt. Könntest Du mir ein einfaches Beispiel schicken, das bei Dir scheitert? Gerne per Mail. Das würde bei mir etwas herumprobieren vermeiden helfen.

[routeconverter]

Ich habe 2 Varianten implementiert: die naive lädt erst alle Routingdaten aber meistens viel zu viel, da sie gar nicht abbricht.
https://github.com/cpesch/RouteConverter...exceptions

Die zweite dreht am Algorithmus und verschiebt das Laden und Initialisieren der Daten in die Kalkulation der Route. Das erlaubt "Lazy Loading":
https://github.com/cpesch/RouteConverter...ceptions_2

Ich würde jetzt die letzte Variante intensiver testen und verfeinern.

[thomas.friese]

Ich würde jetzt die letzte Variante intensiver testen und verfeinern.

Ja, halte ich auch für die bessere Lösung als die andere.

[routeconverter]

Ich habe die Varianten 2 jetzt in die neueste Vorabversion integriert. Was ich noch nicht getestet habe, ist, wie sie sich bei Routen mit vielen Positionen verhält. Das dürfte durch den größeren Overhead - statt 1x pro Route 1x pro Positionspaar - länger dauern.