[GraphHopper] Graphhopper sending back "not found"

Tue Jun 17 14:59:54 UTC 2014

Ah, sure, thanks for the explanation - that mismatch could make indeed 
those problems on the routing side!

When 'solving' those problems: the safest way would be to completely 
remove such oneway streets? So that request go to nearby locations.

Because marking those way as two-way is problematic (?)

> I would make a pull request but I have to fix my github account first...

ok, thanks! (I or you ... whoever comes first ;))

Regards,
Peter.

> Hi Petr,
> I would make a pull request but I have to fix my github account first...
>
> Regarding the second case, the example I found is
> http://www.openstreetmap.org/way/27565747, basically the area on the
> east of the way is a bus station, and is marked as access=private, ie
> only public buses from the city are allowed there.
>
> The way out is not a private road, and is also a one way only. The
> encoder will discard the osm ways for the bus station (since they are
> access=private) and will make and edge for the way 27565747 which will
> be "no way in but a way out"
>
>
> Regards
> Bruno
>
>
> On Tue, Jun 17, 2014 at 4:41 PM, Peter <graphhopper at gmx.de
> <mailto:graphhopper at gmx.de>> wrote:
>
>     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
>>
>
>
>     _______________________________________________
>     GraphHopper mailing list
>     GraphHopper at openstreetmap.org <mailto:GraphHopper at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/graphhopper
>
>
>
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper