The resources use a data model that is supported by a set of client-side libraries that are made available on the files and libraries page.
| name | path | methods | description |
|---|---|---|---|
| AlertPatcher |
|
|
|
| BikeRental |
|
|
|
| ExternalGeocoderResource |
|
|
Maybe the internal geocoder resource should just chain to defined external geocoders? |
| GeocoderResource |
|
|
OTP simple built-in geocoder. Client geocoder modules usually read XML, but GeocoderBuiltin reads JSON. |
| GraphInspectorTileResource |
|
|
Slippy map tile API for rendering various graph information for inspection/debugging purpose
(bike safety factor, connectivity...).
One can easily add a new layer by adding the following kind of code to a leaflet map:
var bikesafety = new L.TileLayer(
'http://localhost:8080/otp/routers/default/inspector/tile/bike-safety/{z}/{x}/{y}.png',
{ maxZoom : 22 });
var map = L.map(...);
L.control.layers(null, { "Bike safety": bikesafety }).addTo(map);
Tile rendering goes through TileRendererManager which select the appropriate renderer for the
given layer.
|
| IndexAPI |
|
|
|
| LIsochrone |
|
|
Return isochrone geometry as a set of GeoJSON or zipped-shapefile multi-polygons.
Example of request:
http://localhost:8080/otp-rest-servlet/ws/isochrone?routerId=bordeaux&algorithm=accSampling&fromPlace=47.059,-0.880&date=2013/10/01&time=12:00:00&maxWalkDistance=1000&mode=WALK,TRANSIT&cutoffSec=1800&cutoffSec=3600
|
| LegendResource |
|
|
|
| MunicoderServer |
|
|
|
| PlannerResource |
|
|
This is the primary entry point for the trip planning web service. All parameters are passed in the query string. These parameters are defined as fields in the abstract RoutingResource superclass, which also has methods for building routing requests from query parameters. This allows multiple web services to have the same set of query parameters. In order for inheritance to work, the REST resources are request-scoped (constructed at each request) rather than singleton-scoped (a single instance existing for the lifetime of the OTP server). |
| PointSetResource |
|
|
This Jersey REST Resource creates and lists PointSets. PointSets serve as destinations in web analyst one-to-many indicators. They can also serve as origins in many-to-many indicators. PointSets are one of the three main web analyst resources: Pointsets Indicators TimeSurfaces |
| ProfileResource |
|
|
A Jersey resource class which exposes OTP profile routing functionality as a web service. |
| RepeatedRaptorTestResource |
|
|
For debugging |
| Routers |
|
|
This REST API endpoint allows remotely loading, reloading, and evicting graphs on a running server. A GraphService maintains a mapping between routerIds and specific Graph objects. The HTTP verbs are used as follows to manipulate that mapping: GET - see the registered routerIds and Graphs, verify whether a particular routerId is registered PUT - create or replace a mapping from a routerId to a Graph loaded from the server filesystem POST - create or replace a mapping from a routerId to a serialized Graph sent in the request DELETE - de-register a routerId, releasing the reference to the associated graph The HTTP request URLs are of the form /ws/routers/{routerId}, where the routerId is optional. If a routerId is supplied in the URL, the verb will act upon the mapping for that specific routerId. If no routerId is given, the verb will act upon all routerIds currently registered. For example: GET http://localhost/otp-rest-servlet/ws/routers will retrieve a list of all registered routerId -> Graph mappings and their geographic bounds. GET http://localhost/otp-rest-servlet/ws/routers/london will return status code 200 and a brief description of the 'london' graph including geographic bounds, or 404 if the 'london' routerId is not registered. PUT http://localhost/otp-rest-servlet/ws/routers will reload the graphs for all currently registered routerIds from disk. PUT http://localhost/otp-rest-servlet/ws/routers/paris will load a Graph from a sub-directory called 'paris' and associate it with the routerId 'paris'. DELETE http://localhost/otp-rest-servlet/ws/routers/paris will release the Paris Graph and de-register the 'paris' routerId. DELETE http://localhost/otp-rest-servlet/ws/routers will de-register all currently registered routerIds. The GET methods are not secured, but all other methods are secured under ROLE_ROUTERS. See documentation for individual methods for additional parameters. |
| SIsochrone |
|
|
This is the original Isochrone class provided by Stefan Steineger. Another implementation has been provided by Laurent Grégoire (isochrone2). |
| ScenarioResource |
|
|
Presents saved non-destructive transit analysis scenarios as a document tree for manipulation via HTTP. |
| ScriptResource |
|
|
Run an uploaded script. This is unsafe, enable it with care. TODO Enable role-based permissions. |
| ServerInfo |
|
|
|
| SimpleIsochrone |
|
|
This class provides a vector isochrone generator for places without good OSM street connectivity, or for graphs that are too large-scale to bother with modeling streets (e.g. all of China). It assumes constant speed through both streets and "free space" around vertices, yielding isochrones that are the union of many circles. The origin snapping option used here (connect to all stations within M meters of a lat/lon) should be made into a standard query option in OTP. Instead of specifying an origin station search radius, it could be more coherent to use all stations within (maxIsochroneTime * speed) meters, and apply a travel time to reach them. The GET methods both use makeContours which in turn uses makePoints (where range checking occurs). Putting "@Setter" on all the parameters would allow resource classes to be used outside Jersey. |
| SurfaceResource |
|
|
Surfaces cannot be isolated per-router because sometimes you want to compare two surfaces from different router IDs. Though one could question whether that really makes sense (perhaps alternative scenarios should be "within" the same router) |
| TileService |
|
|
NOTE This way of fetching travel time tiles does not currently work. It relied on an SPT cache which would find existing SPTs based on search request parameters. Server side stored search results are now done explicitly with TimeSurfaces. See org.opentripplanner.api.resource.SurfaceResource, functions createSurface and tileGet The basic idea is to create a surface for a "batch" or one-to-many OTP search, then using the returned ID fetch the tiles from a URL under that surface ID. |
| TimeGridWs |
|
|
A Jersey web service resource class that returns a grid with time for a set of points.
Example of request:
http://localhost:8080/otp/routers/bordeaux/timegrid?fromPlace=47.059,-0.880&date=2013/10/01&time=12:00:00&maxWalkDistance=1000&maxTimeSec=3600&mode=WALK,TRANSIT
|
| UpdaterStatusResource |
|
|
Report the status of the graph updaters via a web service. |