[GraphHopper] Graphhopper sending back "not found"

Thu Jun 26 16:18:50 UTC 2014

Hi,

I have just issued the pull request.

Tell me if you have any remarks.

Thanks,

Christophe

*De :* Pascal DANEK [mailto:pdanek at kds.com]
*Envoyé :* jeudi 26 juin 2014 17:12
*À :* GraphHopper Java routing engine
*Cc :* Christophe Garreau
*Objet :* Re: [GraphHopper] Graphhopper sending back "not found"

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 <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 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
<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/20140626/2213ce24/attachment.html>