[GraphHopper] Graphhopper sending back "not found"

Tue Jun 17 14:53:22 UTC 2014

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> 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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140617/67ef0a84/attachment.html>