[GraphHopper] Graphhopper sending back "not found"

[Peter]

Hey Pascal,

yes, sure. See e.g. the code and unit tests for PrepareRoutingSubnetworks

Regards,
Peter.


> Thanks Peter,
>
> I will follow your guidelines, but not sure how to work on the graph. 
>
> Is there any sample I could use to know how:
> 1. Load graph
> 2. Traverse graph (ingoing and outgoing)
> 3. Remove nodes
> 4. Save graph
>
> Thanks for your help,
>
> ---pascal
>
> Le 16 juin 2014 à 21:52, graphhopper <graphhopper at gmx.de
> <mailto:graphhopper at gmx.de>> a écrit :
>
>> 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/4deef153/attachment.html>