ProjectPlan
The primary goals for OpenTripPlanner are:
-
Develop a complete open source multi-modal trip planner building on existing open-source trip planning and routing tools
-
Build a healthy development community to ensure long-term growth and support
-
Deploy working trip planning system using TriMet's datasets for use in Portland
-
Test usability and accuracy of trips planned using the new system
Further, the project is guided by several broad directives to be taken into account throughout the development process. Chief among these are:
==== Community ====
Open source projects flourish when backed by a passionate and dedicated community of developers and users. Such communities, however, arise neither overnight nor spontaneously. Their development requires sustained and careful effort on the part the founding contributors to cultivate an environment that is both inviting and accessible to would-be contributors, helping them become more involved in the project as time progresses.
==== Usability ====
One point that became clearly evident during the Portland workshop is that existing trip planners frequently fall short in terms of usability. For instance, existing software provides users with inadequate, misleading and sometimes unnecessary error messages. This has been a point of frustration for many agencies with their current trip planning solutions. Toward this end, OpenTripPlanner will avoid frivilous and unhelpful error messages, instead providing user friendly error messages and only when appropriate and actually required. (Note that getting deeply into the UI is out of scope here -- to start, we are simply going to replace TriMet's backend trip planner with OpenTripPlanner for use inside the system map at http://ride.trimet.org.)
==== Modularity ====
Given the complex nature of trip planning software and the diversity of systems and software stacks a trip planner is likely to be used in conjunctiion with, a driving goal of the project is to maintain a high degree of modularity. Where reasonable, components should remain useful on their own in addition to being part of the larger system.
==== Deployability ====
In order to encourage adoption and use at additional transit agencies, an effort will be made to ensure that the process of deploying an instance of OpenTripPlanner is as painless as possible. The multiplicity of potential installation environments precludes a one-click process, however, thorough documentation and intelligent design decisions can help to make installation and configuration straightforward and reliable.
Below are the major components and milestones for the project. Where appropriate, specific tickets are referenced; eventually, all of the work here should be ticketed and broken into milestones so we can better track and understand our progress. Note also that there is obvious overlap even across the work areas and work need not (and likely cannot) proceed in a strictly serial fashion. For example, parts of area three (packaging and documentation) should go forward in parallel with area two (the core development work).
This includes the initial setup, infrastructure, decision-making, and planning that will help make the later development work a success.
-
Establish project name, domain, and basic infrastructure, including issue tracker, mailing lists, source code management, and initial documentation (much of this has been completed as part of this website: http://opentripplanner.org) (#10, #13)
-
Compare performance and test language differences in core routing engine. (#2)
-
Design trip planner Application Programming Interface (API) (#4)
-
Finalize technical decisions and begin implementing core engine (#2, #4)
This includes the development of the core components of the software by building off of the foundational work done in the initial phase. These components are largely taken from the draft architectural diagram that was developed during the technical session at the Portland workshop.
-
Core routing engine - (comprised of the graph manager and route server in the architectural diagram) - includes code that compiles the graph from the data store and the algorithm that generates the best path through the network given input constraints. (#6)
-
Narrative engine - prepares the final human-readable trip for the client from the path through the graph.
-
Data store and manager - (the "resources" and coresponding logic box in the diagram) for loading and using existing datasets, including transit graphs and schedules. The data store will also communicate with the narrative engine, allowing for service advisories to be overlayed onto the final trip where appropriate. While initially consiting solely of static data (e.g., GTFS schedule files), this componenet could eventually grow to support certain real-time data sources that could be taken into account by the routing engine itself, though this is presently beyond the scope of our current work. (#7)
-
Front-end user interface - widgets used in actually querying the trip planner, e.g., from a website. This work will be based largely off of TriMet's existing front-end as well as parts of the Five Points' user interface. Ultimately, we hope to factor out common elements from these projects and use them as the basis for a GeoExt-based "Transit Widgets" library, which could be used as an off-the-shelf toolbox for developers building transit-related web applications. (#8, #9)
-
Administrative user interface - interface for performing administrative tasks, e.g., updating the graph data. (#5)
This section includes the work that is outside the core development but which is still essential to a successful project.
-
Write and maintain high quality, useful documentation
-
Develop and test project packaging and installation scripts to make deployment and configuration straightforward and reliable
-
Build test system for testing trip planner on real data (#11, #12)