[GraphHopper] Graphhopper sending back "not found"
Peter
graphhopper at gmx.de
Wed Jun 18 16:11:47 UTC 2014
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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140618/2a54f139/attachment.html>
More information about the GraphHopper
mailing list