Architecture
A page to flesh out the high-level architecture developed at the Portland workshop (see notes here) by clarifying what the various components do and how they will be built.
This needs to load in data from the resource layer and compile it into a graph. Should we use a homegrown graph implementation or an existing library (see #14)? How should we proceed here? At the workshop we decided this should be factored out of Graphserver as #6. This has already been started to some extent with Brandon's work with Java Graphserver.
This will take the graph compiled by the graph manager and calculate the shortest path tree (right now we're using Dijkstra's algorithm to get the path, though we could try A* as well). This is still very much tied to the graph manager above. Thoughts as to how the graph manager and route server should be separated?
The code that traverses the SPT and generates the text and other user-facing data for the trip. This should support both multiple languages and full and abbreviated directions (e.g., for mobile devices). It should also communicate with the resource layer for overlaying trip advisories onto the final output (it'd be ideal to have the graph manager take into account real-time or near real-time updates in the data but this isn't in the current scope).
Given that OTP will be used in a lot of different setups, this will need to be pretty flexible. We'll certainly want to read GTFS, OSM, NED, etc (what other formats do we need to support?) and store the data in some reasonable way (e.g., like Graphserver's process_gtfs command which generates a SQLite database). For storage, it'd nice to support multiple databases. If we go this route it shouldn't be too tough to support multiple SQL variants, e.g., SQLite and Postgres (SQLite has the nice advantage in that it takes virtually nothing to set it up). The big question here is what the interface/type of data store should be.
See the API page and #4.
We decided at the workshop to factor out GUI widgets from the existing TriMet and Five Points interfaces (see #8 and #9) into a widget library using GeoExt.
Much of this has already been done by David in Five Points. David, you mentioned in an email that you'd done more work here, do you have an update?