[GraphHopper] Graphhopper sending back "not found"
Peter
graphhopper at gmx.de
Thu Jun 26 15:08:58 UTC 2014
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 <http://graphhopper.com/maps> come
from ?
Also from the GraphHopper Web API <http://graphhopper.com/#enterprise>,
where technically the address suggestion comes from the photon
<https://github.com/komoot/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 <http://graphhopper.com/maps>
> come from ?
>
> Thanks,
>
> ---pascal
>
> Le 19 juin 2014 à 00:04, Bruno Carle <bruno.carle at gmail.com
> <mailto: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
>> <mailto: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
>>> <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/20140626/416800af/attachment.html>
More information about the GraphHopper
mailing list