[GraphHopper] Strange results for GraphHopper paths

[Joel Haasnoot]

Hi Peter,
It took a while, but I've isolated the error in a small subset of
data, that I've uploaded to http://waarisdetrein.nl/download/sph.osm .
The error occurs when you click from any point on the left-most leg
(identified as 4 in my graph) to anywhere else - anything from about
halfway onwards. A screenshot of it in the MiniGraphUI (which is
actually very helpful is here): http://i.imgur.com/R90taGf.png

I realize that there's a lot of overhead in using the standard
implementation of graphhopper, (I've disabled the contraction
hierarchies), but my use case isn't very complicated. Or would it be
better to implement my own reader and use that? I'd rather reuse
what's already available if possible.

Thanks

Joel Haasnoot
----------------------------------------------------------
Joel Haasnoot


On Tue, Jul 16, 2013 at 7:52 AM, Peter K <peathal at yahoo.de> wrote:
> Hi Joel,
>
> if there is a bug (which would be very important to fix), such
> "flip-flop" paths could occur when the extraction of a path (Path4CH)
> does not work properly.
>
>> So far so good, but as of yesterday, making any change to the OSM file in JOSM is creating very strange paths.
>
> It would be very good if I could somehow debug the code to see what is
> going on. So I need either a failing test case with the master branch of
> graphhopper or your modified fork and the data otherwise I can only pray ;)
>
>> The reason I'm using the ngmip fork is to be able to route between these arbitrary coordinates
>
> If you have this complete different use case you might be more happy if
> you just create the graph within a new "rail reader" as you don't need
> OSM attributes, no pillar/tower node optimizations, cars/bikes etc. Have
> a look into the simplistic PrinctonReader where you just create edges
> via g.edge and additionally you can set the coordinates via
> g.setNode(internalNodeId, lat, lon), you can also create a simple
> rail-FlagEncoder based on the existing car encoder for example.
>
> Regards,
> Peter.
>
>> Hi,
>> I've been using the ngmip fork of graphhopper for a bit of an
>> unconventional use - to route railway segments (many would call this
>> "one big hack").
>>
>> I've got a shapefile of all the railway lines, that's been converted
>> into an OSM file with JOSM, marking ways as 'highways="primary"'. I
>> then route between each unique pair of train stations in the
>> Netherlands by coordinates, to be able to create national map based on
>> precomputed segments, to be able to use for disruptions and individual
>> trains. The reason I'm using the ngmip fork is to be able to route
>> between these arbitrary coordinates - stations are often halfway
>> ways/noes.
>>
>> So far so good, but as of yesterday, making any change to the OSM file
>> in JOSM is creating very strange paths. Even the smallest change in
>> totally unrelated ways is triggering "flipflopping" - see this
>> screenshot: http://i.imgur.com/hqpozAi.png
>> I tried doing a diff between the two OSM files, but it seems more than
>> just deleting a few nodes is happening.
>>
>> Does anyone have a sense of what might be happening? Is this a JOSM
>> bug, or is it related to how GraphHopper handles OSM? Or is this an
>> issue specific to the ngmip fork?
>>
>> If need be, I can upload the correct and misbehaving OSM files.
>>
>> Thanks in advance,
>>
>> Joel Haasnoot
>>
>> _______________________________________________
>> GraphHopper mailing list
>> GraphHopper at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/graphhopper
>>
>
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/graphhopper