problem with routing / SPT generation in 0.9.2?

[Stefan Steiniger]

Hi David & Andrew and others,

I would like to report an issue that is difficult to describe.
What might be said is that the routing seems to fail. Where and why this
happen is totally unclear to me. The only idea I have is: something
happens to the graph in the memory. So maybe it is even an issue with my
Mac... and having too few ram (graph 35 MB, mem assigned: 200MB).

What happens:
I am (still) doing walksheds and generate a shortest path tree for a
pushpin location. Then, I am parsing all states and filter out the one
within a certain time. And here it comes..
when I request a walkshed (button: Edges),
(i) for my graph build with 9.2 (from OTP master yesterday) and only
from OSM data
(ii) several times (but waiting for each response)
(iii) around a similar location
then, at some point, I get "these" routing errors.

I attach two images:
The first time when I recognized this behaviour (image:
screenshot_weird_graph.png) two of the walkshed edges/street even
disappear into Neverland. With that came console messages that i attach.

Then I did a restart (Tomcat & Eclipse but this time not in debugging
mode but normal run mode) and the thing happend again. But not with the
a display of weird edge/street drawings and also without the console
output from the first time. But as can be seen in the second image
(screenshot2.png) the first set of edges, 1-2 degrees from the puhspin
location, is not drawn. Again this happened after a couple of times of
clicking/requesting (10x?) around the same location. Btw. the one
cul-de-sac edge shown by mapbox, left to the pushpin, is never displayed
or snapped to - and it is also missing in the graph.
Orange dots in the image present the states/nodes < X mins.
That edges are not displayed may be because they are either not
retrieved from the states that pass the test. Or they are retrieved but
fail the time test for both endpoints.

I have not noticed that behaviour before with 0.7.10 ... but maybe its
just a testing thing, as my graph was much smaller earlier.

I attach my walkshed code (just one class) including my webpage code
(the latter based on "Analyst" code/files).

I also put my zipped graph here:
http://geo.uzh.ch/~sstein/etc/Graph.zip

hope you guys have a guess what happens. If it is just a problem with my
machine, well, then so be it. The next days I can also look what happens
when I run it on our Ubuntu server.

cheers,
stefan

PS: along with my update to OTP 0.9.2 I updated the OpenJUMP OTP graph
display plugin. I figured that information on the Edge-Movement-Mode was
discarded and that a dependency to guave was introduced.

[Stefan Steiniger]

in case my other email did not make it due to content filters...
here it comes again
===

I also put my zipped graph here plus the js/java/html files:
http://geo.uzh.ch/~sstein/etc/

[Stefan Steiniger]

Hi,

so after thinking about the "memory reason" for a while and then looking
at all the orange dots at non-sensical locations in image 2, I got an
idea what the reason is. It is the use of:
graph.streetIndex.getClosestVertex(...)

I am inserting every time a vertex, which seems to be permanent.
And splitting the graph/edge more and more seems to result in the shown
effects. That is why there are in some places so many orange dots. I got
results similar to image 1 after about 8-9 clicks along a large
edge/road with slight changes in the pushpin location (10m?).

Am I using the above method incorrect? or is this a bug?

And once, JSON was actually throwing this, when I tried to return the
geometries:

net.sf.json.JSONException: JSON does not allow non-finite numbers
at net.sf.json.util.JSONUtils.testValidity(JSONUtils.java:555)
...what ever this means...
maybe it is because a geometry got some strange coordinates?

stefan

Am 18.10.12 19:40, schrieb Stefan Steiniger:

[Andrew Byrd]

Hi Stefan,

I think you have found an explanation for your problem. I am guessing
you are repeatedly sub-dividing the edges and eventually creating a
situation that produces an invalid (NaN or Infinity) value. OTP should
at least tolerate a bunch of edge-splitting in the same location, so I
am ticketing the problem you described. Triggering it would be much more
probable with many tiny temporary edges in the graph though.

getClosestVertex(...) is a low-level method, and if you call it directly
the temporary edges it creates will not be automatically removed from
the graph. The higher-level way to perform a search uses a
RoutingContext to handle the setup and teardown.

I see that your walkshed resource is already a subclass of
RoutingResource, and you are using the stock superclass method to
construct a RoutingRequest. However, you are then manually extracting
the 'from' location from the request and linking it into the graph. You
probably want to call
RoutingRequest.setRoutingContext(graphService.getGraph(routerId)) which
will handle this for you. Then, when you are done handling your request
you can call RoutingRequest.cleanup() to remove any edges.

An optimization: instead of filtering a complete SPT, you can set
RoutingRequest.worstTime to break out of the search at 60 minutes and
your SPT should only contain the edges you care about. The
GenericDijkstra doesn't seem to respect this limit. The GenericAStar
SPTService in batch mode will do what you want though.

The fact that there is a circular reference between RoutingRequest and
RoutingContext is questionable, and is just a result of the fact that
RoutingContext groups together fields that were previously part of
RoutingRequest (when it was a TraverseOptions), and not wanting to break
a bunch of existing tests. The purpose is to separate the parameters
that permanently identify (in the hash/equals sense) a routing request
from the (ephemeral) details of how it is being carried out on a
specific graph. Maybe in some future refactoring we can avoid the
awkward 'null' rctx.

-Andrew

[Stefan Steiniger]

Hi Andrew,

your suggestion to use RoutingRequest.setRoutingContext() and then call
cleanup seems to me exactly what I need - thanks a lot!!!
that should help me to keep going.

now lets check how I can change things.

one more time a big thank you,
stefan


Am 19.10.12 05:12, schrieb Andrew Byrd: