[GraphHopper] Graphhopper sending back "not found"

Peter graphhopper at gmx.de
Tue Jun 17 14:41:10 UTC 2014


Thanks Bruno,

I try to integrate this into GH when I have time (or someone other can
add some basic unit tests + add it as pull request)

Considering your second case, I do not understand it fully. If it is not
a map problem, then how can a vehicle get there? (Even if it is a
service highway)

Regards,
Peter.

> Hi,
> I just wrote a small class that fixes this kind of issues. Basically
> it looks for nodes where there is a way in but not out (and
> vice-versa), and disable all edges around the node. It seems to work
> fine so far. I Think islands will not be a problem but I have not
> tested it since I don't have any islands on the area I am working on.
>
> For cases when there is no way out but there is a way in, I believe
> most likely it is a problem on the map.
> For cases when there is no way in but a way out , I believe the map is
> correct: e.g. http://www.openstreetmap.org/way/27565747, and hence
> this should be addressed in GH.
>
> This  is how to call it: (if you have multiple encoders you ll need a
> way to retrieve the encoder's directionBitMask)
>
> @Override
> public GraphHopper importOrLoad(){
>             super.importOrLoad();
>            
> FixOneWayDeadEnds.fixAllOneWayDeadEnds(this.getGraph(),getEncodingManager().getSingle(),3l);
>             return this;
> }
>
>
> Cheers
> Bruno
>
>
>
>
>
>
> On Mon, Jun 16, 2014 at 9:52 PM, graphhopper <graphhopper at gmx.de
> <mailto:graphhopper at gmx.de>> wrote:
>
>     Yeah this is a frequent requested feature but not hard to implement:
>     http://graphhopper-read-only-archive.1087335.n5.nabble.com/Issues-detecting-driving-paths-along-one-way-streets-td1002.html#a1003
>
>     But this would mean hiding the real OSM issues ...
>
>     Regards,
>     Peter.
>
>>     Hi Peter,
>>
>>     We played with the settings (minNetworkSize and highResolution)
>>     and it solved a certain class of problems. However, most of the
>>     requests still fail. After deeper investigation, we discovered it
>>     is due to one of the two points using a way which is a oneway,
>>     leading to a subnetwork from which you can't return. It occurs in
>>     many airports or within private areas.
>>
>>     I think it is a bug in data, but despite of this, I believe
>>     Graphhopper should manage that properly in order to make it
>>     really useable. (osrm has the same issue). I mean, we have
>>     thousands of requests which fail.
>>
>>     What we did for now: We implemented in the web service an option
>>     specifying that the service, in case of a "not found", move start
>>     or destination point (alternatively) within a certain distance,
>>     until it finds a route. This actually solve the problem by making
>>     the routing service using a routable way. Are you interested by
>>     this patch ?
>>
>>     Of course, it is only a workaround, maybe not suitable for a long
>>     term solution. We think that a correct way to fix this would be
>>     to clean the graph, at the prepare stage, removing nodes after a
>>     one way if they are less than N. What do you think about this ?
>>
>>     ---pascal
>>
>>     Le 2 juin 2014 à 10:48, Peter K <peathal at yahoo.de
>>     <mailto:peathal at yahoo.de>> a écrit :
>>
>>>     Hey Pascal,
>>>
>>>     there are cases with oneway where it wouldn't be logical to
>>>     return a route. Still there are workarounds like described here:
>>>     https://lists.openstreetmap.org/pipermail/graphhopper/2014-May/000960.html
>>>
>>>     But in your case it is a mapping problem with the incorrect
>>>     oneway somewhere here:
>>>     http://graphhopper.com/maps/?point=43.697867%2C7.121721&point=43.69784%2C7.121657
>>>
>>>     which makes the whole district in the south unavailable.
>>>
>>>     Regards,
>>>     Peter.
>>>
>>>
>>>>     Hello folks,
>>>>
>>>>     I am Pascal and  I currently evaluate Graphhopper as an
>>>>     alternative routing service for my company.
>>>>
>>>>     We are currently facing an issue with an itinerary: from "Nice"
>>>>     to "St Paul de vence", we just get a "not found" response from GH.
>>>>
>>>>     I tested the official online instance and I get the same behaviour:
>>>>     http://graphhopper.com/maps/?point=nice%20&point=saint%20paul%20de%20vence
>>>>     <http://maps.ad-kds.lan.net:8900/?point=43.703002,7.265224&point=43.694687,7.124634&locale=fr-FR>
>>>>
>>>>      
>>>>
>>>>     Whereas the opposite works fine:
>>>>     http://graphhopper.com/maps/?point=saint%20paul%20de%20vence&point=nice
>>>>
>>>>     Is it a bug related to some kind of one way direction ?
>>>>
>>>>     Should I submit a bug, or do I miss something ?
>>>>
>>>>     Thanks in advance for your help,
>>>>
>>>>     ---pascal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140617/fd51a3e1/attachment.html>


More information about the GraphHopper mailing list