[GraphHopper] Graphhopper sending back "not found"
Pascal DANEK
pdanek at kds.com
Thu Jun 26 15:12:12 UTC 2014
> Did you apply this to the whole world or a smaller area?
On the planet :-)
> sounds good. Would really like to see it in code and invite you to do a pull request!
OK cool, so we will add some tests and send it !
—pascal
Le 26 juin 2014 à 17:08, Peter <graphhopper at gmx.de> a écrit :
> Hey Pascal,
>
> sounds good. Would really like to see it in code and invite you to do a pull request! Did you apply this to the whole world or a smaller area?
>
> > I have an aditional question: can you tell me where does the autocomplete in graphhopper.com/maps come from ?
>
> Also from the GraphHopper Web API, where technically the address suggestion comes from the photon project which uses ElasticSearch.
>
> Regards,
> Peter.
>
>
>> Hello,
>>
>> So we finally implemented a change which work for us:
>>
>>
>>
>> Compare to:
>>
>> http://graphhopper.com/maps/?point=nice&point=saint%20paul%20de%20vence
>>
>> Here is the algorithm :
>>
>> - First loop on nodes using a one-way explorer ;
>> - It gives a list of all the sub-networks with their size ;
>> - Sort the list by size (bigger first) in order to keep the big networks and kill all small networks (size < minNetworkSize). We can use another property if necessary.
>> - For each sub-network (identified by its first nodeid) explore all nodes starting from this nodeId and not in the big networks (>minNetworkSize) and remove them ;
>>
>> The algorithm is done twice (forward and backward).
>>
>> Let us know if it is something interesting for you. We will fix and add tests and send you a pull request.
>>
>> I have an aditional question: can you tell me where does the autocomplete in graphhopper.com/maps come from ?
>>
>> Thanks,
>>
>> —pascal
>>
>> Le 19 juin 2014 à 00:04, Bruno Carle <bruno.carle at gmail.com> a écrit :
>>
>>> 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
>>>>>>>>>
>>>>>>>>> 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/20140626/71e541ed/attachment.html>
More information about the GraphHopper
mailing list