Isochrone fixes - #1436

[laurentg]

2f65e8b is unrelated but is rather useful for publishing client file "on the fly".
8f35de6 (re-) add a small demo client for vector isochrones development/debug.
This add a new parameter "offRoadDistanceMeters" which is now completely independent from the grid cell size.

[abyrd]

Thanks Laurent for all these contributions. I still need to study the closing process in more detail but will merge this now as it looks like a real step forward.

[abyrd]

@laurentg a few details you might be interested in:

We are working quite a bit on OTP Analyst these days, including server-side support for cached pointsets (previously known as populations) and shortest path trees (or their leaves, or other intermediate representations). So rather than fetching a timesurface or isochrones directly in one shot, we are requesting an SPT, then a reference or identifier for the leaves of that SPT is passed back to the client (via web API or using OTP directly as a JAR library). Then the client can ask for isochrones, time grids, tiles, evaluate point sets etc. for those cached SPTs. It's a trade off in that it becomes a 2-step transaction and memory is consumed for the SPT / triangulation cache but there are certainly benefits.

Here's an example of why we're doing this, in a project with Waag Society:
http://abyrd.github.io/otpa-web/#dev.opentripplanner.org:9090/otp

This will also be used in the general spatial analysis platform that Conveyal is working on, to be delivered as a beta in mid-July.

Laurent, what would you think about switching entirely to this kind of web API (which you'll find at org.opentripplanner.api.resource.SurfaceResource) and replacing the one-shot web API endpoints with this new system. I ask mostly because there is duplicated code between the two approaches.

We also want to move in the direction where the web API functions are very simple wrappers around a native API, i.e. public functions and classes that allow us to build custom apps on top of OTP without talking to it over HTTP.

-Andrew

[abyrd]

Note that some of the UI components are a bit rough, you might have to reload or move the origin point if something glitches.

[laurentg]

@abyrd Thanks for the info. I don't see any point against switching to this new interface. That would probably complexify a bit a "simple" client but that should be manageable.

The Amsterdam demo looks nice. Just for the info, the background map regarding water is wrong in many places (I told you that because initially I did not recognized the place I used to live in Amsterdam.) Is the code in OTP master?

As for having http request a thin wrapper around a stable "library" API, I'm fully for this. I've seen too many design horrors (and there are still some in OTP...), with bunch of business logic in Jersey wrapper classes.

[abyrd]

@laurentg thanks for your comments. I can of course see a disadvantage to the new system: when someone needs only a single isochrone and no other services, the travel time surface is still cached and there is no absolute guaratee that it is not evicted between the SPT creation request and the isochrone request. However if the "native" API is designed right it should be possible to eventually make an additional HTTP API method that is still a thin wrapper, but creates an SPT, makes it into an isochrone, and discards it all in a couple of lines of code, bypassing the cache. Or cache entries could even be marked as throwaway (i.e. slated for rapid eviction after being used once). None of that is particularly important currently though.

Not sure about the Amsterdam map tiles, @bertspaan would know more about it. However he is now biking through the Rocky Mountains so we might have to be patient for any changes :)