... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
GraphHopper Routing Exception
#1
Hi,

I am Using GraphHopper (with bike setting) and get the following (two similar) exceptions while routing on the border of the "oberbayern" and "schwaben" routing data:

SEVERE: Cannot route position list: 'com.graphhopper.util.exceptions.PointNotFoundException: Cannot find point 1: 48.33591627071882,11.07885431020705'

Watching DownloadableFinder.getDownloadableFor() I can see that the file: europe/germany/bayern/oberbayern-latest.osm.pbf is selected as data, based on the center distance and inclusion of the bounding box of the two waypoints in the bounding box of the file. However... then the point seems to not be present in the Oberbayern data ... continuing then within "schwaben" that decision then swings to the next tile of Routing data and then it works properly again


Error route (within Oberbayern Bounding Box):

longitude=11.141854035548846, latitude=48.325759113802

longitude=11.07885431020705, latitude=48.33591627071882



Success (within Schwaben Bounding Box):

longitude=11.07885431020705, latitude=48.33591627071882

longitude=10.988045441798846, latitude=48.35131933232875



Oberbayern

NW Corner: longitude=10.71268, latitude=49.09052

SE Corner: longitude=13.10138, latitude=47.39037



Schwaben

NW Corner: longitude=9.397266, latitude=49.0366
SE Corner: longitude=11.31348, latitude=47.11463




My theory here: the bounding box of the file is too generous for the actual content (a bit of OSM-Data missing at the edge of Oberbayern towards Schwaben).


Is that a known problem?
Are there easy tools to visualize the Routing Data content and see what is missing / included in which file?

Regards,
Thomas
Reply
#2
Moin Thomas,

da RouteConverter aus dem schönsten Bundesland der Republik stammt, darfst du ruhig die deutsche Sprache nutzen.
--
Matthias
Reply
#3
Hallo Matthias,

ups...  Gewohnheit aus der täglichen Arbeit und ein englischsprachiges Foren-UI haben mich da ins englische hineinfallen lassen.

Zusammenfassung in Kürze:

GraphHopper wirft eine Exception im Bereich in dem sich die Planungs-Karten-Daten von Oberbayern und Schwaben überlappen, die Bounding-Box der Route liegt sowohl vollständig in der Bounding-Box von Oberbayern als auch in der Bounding-Box von Schwaben, der "Zentrums-Abstand" lässt den den DownloadableFinder in der getDownloadableFor() Method das Material von Oberbayern bevorzugen, da knallt es dann aber:

SEVERE: Cannot route position list: 'com.graphhopper.util.exceptions.PointNotFoundException: Cannot find point 1: 48.33591627071882,11.07885431020705'

Nachstellen kann ich es mit dem aktuell aus dem git geclonten Code auf der St 2051 mit einem kurzen Wegstück vor "Eurasburg (Schwaben)"

Kennt jemand solche Fehler, tritt sowas öfter auf, lohnt es sich dem Fehler mal nachzugehen?

Falls es bekannt ist weil sowas an den Nahtstellen der Karten auftritt könnte man entweder auf die Karten, den Bounding-Box Ansatz, oder die Strategie z.B. mit dem Auftreten des Fehlers umzugehen zielen.


Gruß
Thomas
Reply
#4
(01.08.2019, 20:57)thomas.friese Wrote: ups...  Gewohnheit aus der täglichen Arbeit und ein englischsprachiges Foren-UI haben mich da ins englische hineinfallen lassen.

Hallo Thomas,

Englisch wäre auch ok gewesen.

(01.08.2019, 20:57)thomas.friese Wrote: Kennt jemand solche Fehler, tritt sowas öfter auf, lohnt es sich dem Fehler mal nachzugehen?

Ja, ich kenne solche Fehler. Sie treten immer an den Nahtstellen zwischen den Kartendateien auf.

(01.08.2019, 20:57)thomas.friese Wrote: Falls es bekannt ist weil sowas an den Nahtstellen der Karten auftritt könnte man entweder auf die Karten, den Bounding-Box Ansatz, oder die Strategie z.B. mit dem Auftreten des Fehlers umzugehen zielen.

Du hast den DownloadableFinder ja schon gefunden. Es gibt ja sogar Tests für die Klasse. Aber noch keine für die Nahtstellen.

Das wäre ein Startpunkt: ein Test, der Deinen Use Case nachstellt, und scheitert.
--
Christian
Reply
#5
Ich habe mal geschaut

@Test
public void testSelectOnlyCenterFileIfItCoversTheRoute()

ist scheinbar nicht ausreichend, um Deinen Fehler zu vermeiden.
--
Christian
Reply
#6
(02.08.2019, 10:30)routeconverter Wrote:     @Test
    public void testSelectOnlyCenterFileIfItCoversTheRoute()

ist scheinbar nicht ausreichend, um Deinen Fehler zu vermeiden.

Ok, ich schaue mal ob ich einen Test hin bringe, der den Use-Case nachstellt und entsprechend aktuell scheitert wird etwas dauern.

Wo wir gerade bei scheitern sind:

meine aktuell drängendste Anwendung ist eine Route von Vancouver nach San Francisco, die Route setzen würde ich auf einem Level wo der Downloader Bundesstaaten-Level Karten verwendet. Da bin ich jetzt auf folgende Weise auf die Nase geflogen:

Route von Vancouver aus geplant - also mit British Columbia Karte, beim Übergang nach Washington flog die Exception. Innerhalb Oregons konnte ich wieder planen.

Wenn ich mir die Bounding Boxes ansehe, sind die Folgendermaßen:

British Columbia:
longitude=-142.8716, latitude=60.00678
longitude=-114.049, latitude=45.385

Washington:
longitude=-126.7423, latitude=49.00708
longitude=-116.9145, latitude=45.54326

Der südlichste Punkt der Stateline zwischen Washington und Oregon verläuft in Portland irgendwo bei Latitude > 45.6 

D.h. weil ich ZUERST die British Columbia Karte gezogen hatte, hat praktisch jeder Routenpunkt in Washington state mit dieser Logik hier 

// choose the closest distance of centers but prefer covering existing files if closest distance means download
return existsFile(centerFile) || !existsFile(coveringFile) ? centerFile : coveringFile;

dazu geführt, dass British Columbia angezogen wird und NIEMALS Washington runter geladen wird. 

Workaround: British Columbia gelöscht, kurze Route in Washington geplant --> washington im lokalen Filesystem, DANACH neu von BC aus geplant --> british columbia im lokalen Filesystem und jetzt kann ich quasi seamless planen, übrigens tritt dann der Fehler auch am Übergang nicht mehr auf.

(1) Ich würde gern mal das Kartenmaterial ansehen - weil da die Bounding Box offenbar mehr verspricht als die Karten hergeben <- DAS halte ich für die Root-Cause des Problems aber ich habe Oberbayern mit JOSM nicht auf bekommen (keine Zeit und Out of Memory mit 16 GB auf dem Mac) 

Hast du nen Tip für ein Tool mit dem ich die Karten aufbekomme?

(2) Der Code heute verlässt sich ja quasi auf die Bounding Boxes, die scheinen aber falsche Freunde zu sein. Lösungsansätze:
 
a) lazy-download Strategie lassen: wenn ich immer weiter südlich gegangen wäre, hätte irgendwann das center(WA) näher an der Routen-Box gelegen als das center(BC) und er hätte die WA Karte angezogen und richtig weiter gemacht; weil BC WA quasi vollständig überlagert hatte ich keine Chance mehr das Auswählen und Laden der WA-Karte überhaupt zu triggern, nachdem ich die BC karten schon auf dem Rechner hatte

b) Leider löst a) noch nicht, dass es wohl Bereiche gibt, in denen die falsche Karte (covering + closest aber leider unvollständige Daten) <- das wäre der Oberbayern - Schwaben Testcase. 
Hier wäre eine Strategie: 


wenn route-call zu "point not found exception" mit Karten-Option A führt, dann fall-back 1: nächste Karten-Option Nachbar-Tile, und nochmal route-call, wenn wieder "point not found exception", dann fall-back 2nächstgrößere Karte verwenden und noch mal route-call

c) [Aufwändig, weniger Praktikabel, aktuell nur Theorie mit den Beobachtungen] 

- Kartendaten ansehen und ggf. fixen (also dafür sorgen, dass ALLE Daten innerhalb der Bounding Box auch da sind), oder 
- Bounding-Box Algorithmus anpassen, damit die Bounding Boxes verlässlich alle Daten enthalten die da sein sollten (?! wenn da nicht ein Bug in der Bounding Box ist würde ich ja vermuten, dass einfach die Daten "fehlerhaft" = nicht das volle Rechteck vorhanden sind)

Mich reizt es auch mal, mich etwas im Code orientieren um evtl. b) anzugehen, abgesehen von einen TestCase zu finden und die pbf Daten mal anzusehen
Reply
#7
Mit JOSM und Luxemburg konnte ich mir die Daten ansehen und ich würde mal sagen es knallt weil die Karten-Daten die Bounding-Box natürlich nicht vollständig ausfüllen.

Siehe Attachment: wenn man versucht eine Route in dem schwarzen Nord-Ost-Eck zu planen, dann entscheidet der Downloader brav auf Basis der Bounding-Boxes, dass Luxembourg die Karte ist und der GraphHopper kann dann die Punkte nicht finden (weil sie wie man sieht nicht da sind).

Ausschließlich auf Basis der Bouding-Box kann man das aber nicht entscheiden - daher lässt es sich auch nicht so mocken.

Einen Unit-Test analog zu 

@Test
public void testSelectOnlyCenterFileIfItCoversTheRoute()


wird da nicht so einfach, das läuft wirklich eher auf Szenario b) oder c) raus.


Attached Files Thumbnail(s)
   
Reply
#8
Ich habe das jetzt mal prototypisch implementiert:



- nicht mehr nur ein einzelnes Downloadable mit dem Finder holen, sondern (im Moment noch zusätzlich) eine sortierte Liste.

- wenn beim routing was schief geht den nächsten Eintrag (=nächste Karte) in der Liste nehmen und den GraphHopper neu damit initialisieren und noch mal routen



Damit tritt dann die Exception nicht mehr auf weil er eben etwas trial and error benutzt um eine Karte zu finden, die wirklich auch die benötigten Kartendaten enthält.







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?


Attached Files
.zip   graphhopper_patch_master-2019-07-05.diff.zip (Size: 2.53 KB / Downloads: 8)
Reply
#9
(02.08.2019, 22:02)thomas.friese Wrote: Hast du nen Tip für ein Tool mit dem ich die Karten aufbekomme?

Leider nein. Ich habe das hier gefunden: https://wiki.openstreetmap.org/wiki/DE:PBF_Format

(02.08.2019, 22:02)thomas.friese Wrote: c) [Aufwändig, weniger Praktikabel, aktuell nur Theorie mit den Beobachtungen]
- Kartendaten ansehen und ggf. fixen (also dafür sorgen, dass ALLE Daten innerhalb der Bounding Box auch da sind), oder
- Bounding-Box Algorithmus anpassen, damit die Bounding Boxes verlässlich alle Daten enthalten die da sein sollten (?! wenn da nicht ein Bug in der Bounding Box ist würde ich ja vermuten, dass einfach die Daten "fehlerhaft" = nicht das volle Rechteck vorhanden sind)

Ich fürchte, das ist ein prinzipielles Problem: die Bounding Boxes aus PbfUtil#extractBoundingBox stammen aus der HeaderBBox des OSM PBF-Dateiformats und das definiert nur einen rechteckigen Ausschnitt.
--
Christian
Reply
#10
(04.08.2019, 06:59)thomas.friese Wrote: Ich habe das jetzt mal prototypisch implementiert:
- nicht mehr nur ein einzelnes Downloadable mit dem Finder holen, sondern (im Moment noch zusätzlich) eine sortierte Liste.
- wenn beim routing was schief geht den nächsten Eintrag (=nächste Karte) in der Liste nehmen und den GraphHopper neu damit initialisieren und noch mal routen


Cool. Das scheint eine pragmatische Lösung zu sein.

Eine Frage aus Neugier: Warum hast Du in DownloadableFinder nicht

public Downloadable getDownloadableFor(BoundingBox routeBoundingBox) 

auf eine Liste von Downloadable aufgebohrt?


(04.08.2019, 06:59)thomas.friese Wrote: 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.

Schwierig finde ich

private List<Downloadable> routingTileInfoList;

Denn eigentlich sollte doch

private java.io.File osmPbfFile;

auf eine Liste aufgebohrt werden, oder?
--
Christian
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)