[GraphHopper] Graphhopper sending back "not found"

Wed Jun 18 08:17:09 UTC 2014

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/bf71da2d/attachment.html>