[GraphHopper] Graphhopper sending back "not found"

Tue Jun 17 21:27:02 UTC 2014

Hi Bruno and thanks a lot for sharing,

However it does not work as expected on my side. I can see all logs saying it removes nodes, but it still not works. For example:

http://graphhopper.com/maps/?point=55.948091%2C-3.36423&point=55.953252%2C-3.188267

I guess the Edimbourg drop-off should be removed…

or: http://graphhopper.com/maps/?point=nice&point=saint%20paul%20de%20vence

Does it work for you ?

—pascal

Le 17 juin 2014 à 16:32, Bruno Carle <bruno.carle at gmail.com> a écrit :

> 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> 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> 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
>>>>  
>>>> 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
>>> 
>>> _______________________________________________
>>> GraphHopper mailing list
>>> GraphHopper at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/graphhopper
>> 
>> 
>> 
>> _______________________________________________
>> GraphHopper mailing list
>> GraphHopper at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/graphhopper
> 
> 
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper
> 
> 
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140617/13c0c7aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FixOneWayDeadEnds.java
Type: text/x-java
Size: 2551 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140617/13c0c7aa/attachment.java>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140617/13c0c7aa/attachment-0001.html>