[GraphHopper] Truncated routes

[Emden R. Gansner]

On 6/20/14, 12:24 PM, Bruno Carle wrote:
> Here is the output that I get...
> 115 points
> distance from source to start 89.8181ms
> distance from end to target 38.4730ms
>
> Do you get the same output ?
No, I was getting
75 points
distance from source to start 89.8181ms
distance from end to target 6543.5255ms

I believe I have figured out the problem. I must not be understanding 
the data caching model correctly. I was
concerned that the truncated routes I was seeing was due to a truncated 
OSM data set, so I replaced the argument
to setOSMFile to the larger texas-latest.osm.pbf but kept the argument 
to setGraphHopperLocation the same. Testing
again, I was still getting truncated routes.

Since the test program, the graphhopper code and the raw OSM file were 
the same as yours, I wondered if the routing
was using the old cached data. Indeed, after removing those files, when 
next I called the test program, there was a long delay
as the files were rebuilt, and I ended up with the same answer that you 
reported.

So what is the correct procedure when switching to a new data file? I 
assumed there was some check that the cached data
belonged to the file referred to in setOSMFile, but apparently this is 
not the case. Am I responsible to make sure each new
OSM file gets a clean graphhopper location directory for generating the 
cached files? Or is there some way to tell graphhopper
to enforce this?

Thanks, and sorry for the misunderstanding on my part.

      Emden