Analyst client not working

[clinct]

I'm trying to fire up analyst inside the latest master checkout, but keep on getting 404's on requests.

Building:

java -Djava.io.tmpdir=/tmp/otp -XX:NewRatio=1 -Xms30G -Xmx30G -server -jar "${JAR}" --skipVisibility --longDistance --analyst --build "${BUILD_DIR}"

Running:

java -Djava.io.tmpdir=/tmp/otp -XX:NewRatio=1 -Xms30G -Xmx30G  -server -jar "${JAR}"  --analyst --server --longDistance --graphs "${BUILD_DIR}" --port 9050

For instance the following URL returns a 404 (well, a 500 inside the HTTP headers, but a 404 inside the response)

/otp/routers/default/analyst/legend.png?width=300&height=40&styles=color30

[clinct]

Figured out that the URL above does work if I leave out 'routers/default', so I guess that's just a mismatch between the client and the API. So, this one works:

/otp/analyst/legend.png?width=300&height=40&styles=color30 does work.

However, the tile API of analyst then still seems to be a problem, the below URL just returns a 204:

/otp/routers/default/analyst/tile/11/1049/673.png?batch=true&layers=traveltime&styles=color30&time=10:47am&date=01-15-2015&mode=WALK&maxWalkDistance=804.672&fromPlace=52.28076170665054%252C4.6863555908203125&toPlace=52.28076170665054%252C4.6863555908203125

While inside TileService.java the path is defined in that exact way way:

@Path("/routers/{routerId}/analyst/tile/{z}/{x}/{y}.png")

[abyrd]

are you adding the --analyst command line parameter when you start it up?

[clinct]

Yes, I'm starting OTP up as shown in the first post.

[hannesj]

I think this is the reason for not getting any results. It seems the method signature was changed from rendering routing requests to rendering time surfaces.

[abyrd]

@clinct I only saw your second post before, sorry for the useless question about command line parameters. There is one way to make isochrone tiles that should still work: you use the TimeSurface API to make a time surface for a given request, then using the surface ID that is returned you fetch the tiles. See org.opentripplanner.api.resource.SurfaceResource, functions createSurface and tileGet. This keeps some time surfaces hanging around in a cache, but the other method also keeps whole SPTs in a cache. The only real downside I know of is that you must do two round-trip requests to begin rendering the tiles.

[abyrd]

@clinct also see function differenceTileGet if you want to visualize differences in travel time.

On further examination, I'd say the reason the TileService code is still hanging around is this notion that it might be useful to fetch the tiles "directly" rather than ask the server to create a stored travel time surface then fetch the tiles. But the stateless behavior of the former approach is illusory (significant caching does take place) so it's probably better to switch entirely to the second approach, which is more true to the inner workings on the server.

I'll add some comments to the relevant classes to reduce confusion in the future.

[abyrd]

I'm leaving this issue open, because we need to modify the client to do the following:

1. make a request: POST /otp/surfaces?queryparams...
2. this returns a surface ID
3. in the callback, add a leaflet tile layer for the URL /otp/surfaces/{surfaceId}/isotiles/{z}/{x}/{y}.png

[clinct]

Added a Pull request that does exactly as you pointed out and indeed makes it work again: #1703

[abyrd]

Merged the PR from @clinct that should solve this.