[GraphHopper] Graphhopper sending back "not found"
Bruno Carle
bruno.carle at gmail.com
Wed Jun 18 22:04:35 UTC 2014
Hi Petr,
I agree, visiting and marking the edges sounds like a better solution. But
probably more complicated too because of the 'islands'
Bruno
On Wed, Jun 18, 2014 at 6:11 PM, Peter <graphhopper at gmx.de> wrote:
> Hey,
>
> maybe I don't understand the problem but why not mark all visited nodes
> and remove the remaining?
> In the parking example an outgoingExplorer can reach all its edges and
> won't help, but the second step should be done with the ingoingExplorer and
> will make those nodes none-explorable and so they will be removed.
>
> Regards,
> Peter.
>
> Hi,
> I can imagine a case like this: if a parking consists of several edges,
> and is connected to the rest of the graph thru a one-way edge, the
> FixOneWayDeadEnds will not detect it. (FixOneWayDeadEnds only removes edge
> leading to a point without way out/in )
>
> Maybe something like this happen in your example
>
> Bruno
>
>
>
>
> On Wed, Jun 18, 2014 at 3:52 PM, Pascal DANEK <pdanek at kds.com> wrote:
>
>> Hi Bruno,
>>
>> I updated my version of Graphhopper, updated your code and it now works
>> as expected for Edimbourg and many others, anyway the algorithm.
>>
>> However, it still fails for some.
>>
>> For example:
>> http://www.graphhopper.com/maps/?point=55.862711%2C-4.432372&point=55.864237%2C-4.251806&locale=fr-fr
>>
>> It looks like the parking, which is only accessible in one way has not
>> been removed. Any idea why ?
>>
>> —pascal
>>
>> Le 18 juin 2014 à 10:58, Bruno Carle <bruno.carle at gmail.com> a écrit :
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140619/c493c9fc/attachment.html>
More information about the GraphHopper
mailing list