[GraphHopper] Graphhopper sending back "not found"

Wed Jun 18 08:58:51 UTC 2014

Hi again Pascal,
Please try with astar/astarbi algorithms, as I have not tested with others.
Bruno

On Wed, Jun 18, 2014 at 10:17 AM, Bruno Carle <bruno.carle at gmail.com> wrote:

> Hi Pascal,
> I downloaded  great-britain-latest.osm.pbf from geofabrik and tried your
> Edinburg example and it works fine for me.
> Do you have more than one encoder? If yes please check that the
> directionBitMask are correct.
> Otherwise I can not think right now of something else...
> Cheers
> Bruno
>
>
> On Tue, Jun 17, 2014 at 11:27 PM, Pascal DANEK <pdanek at kds.com> wrote:
>
>> 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
>>> <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
>>>
>>>
>>>  _______________________________________________
>>> GraphHopper mailing list
>>> GraphHopper at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/graphhopper
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> GraphHopper mailing listGraphHopper at openstreetmap.orghttps://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/20140618/d2f6cf73/attachment.html>