-
Notifications
You must be signed in to change notification settings - Fork 72
Roadmap
This page discusses the Roadmap for the near- and mid-term development and support of OneBusAway by the OneBusAway community.
To understand where we're going, it's important to understand how we got to where we are today. Very briefly:
- OneBusAway started as an experimental university research project in the Seattle area for aggregating low-level real-time data from the numerous Seattle-area transit agencies (with existing AVL systems) and making it available to riders and developers through a number of internet and mobile channels. It was a smashing success.
- The public transport provider of New York City, with no AVL system to speak of, began a project (later known as MTA Bus Time) to deliver real-time customer information to the riders of its 6,000-vehicle bus network. A key strategy in this project was the use of open technologies -- open standards interfaces whenever possible, and open source software when appropriate. OneBusAway was a natural fit for the back end of this project, but required many enhancements to support NYC's requirements.
- Some of the enhancements for the NYC project were complementary to the original project in Seattle, either in the form of new modules or fixes to the core. Others, such as new user interfaces and standards-based web services, represent substantive changes to the project.
Given the rapid pace of change that the project has undergone recently, a Roadmap such as is described here is needed to ensure coordinated and effective evolution of the project.
To be very clear: this Roadmap represents a shared understanding amongst the OBA community and its stakeholders about where we all believe the project should go (from a software perspective). It does not imply any commitment whatsoever from any party as to where the resources to go in that direction will come from, nor the timeframe under which we expect to get there.
The objectives driving the Roadmap are to:
- Minimize long-term development/maintenance/support costs for all parties through unification of the codebase
- Allow other parties to take advantage of the new work done in the onebusaway-nyc project
- Minimize the barriers to new deployments of OneBusAway globally
- Through supporting the provision of real-time information to transit riders via web and mobile channels, encourage the use of public transit with all concomitant economic, social, and environmental benefits.
The Roadmap proposal is thus as follows:
- In general, produce more documentation about what has been done as part of the onebusaway-nyc project.
- Move these new modules into one or more repositories under the main OneBusAway github account.
- Use the main onebusaway github account as the single location for publicly accessible and community-driven documentation, issue/bug tracking, etc.
In general: focus on open standards-based API's and highly intuitive, usable, and beautiful user experiences.
- Deprecate the existing OneBusAway web-based UI's (including SMS and IVR which integrate via HTTP).
- Deprecate the use of the RESTful OBA API for any real-time information (but not for 'discovery' functions based on static GTFS data).
- Adopt SIRI as the standard for real-time information coming out of the system, incorporating the recent changes to SIRI to allow for RESTful requests and non-XML (eg JSON) encodings.
- Improve, extend, and/or otherwise adapt the SIRI API's from onebusaway-nyc to meet the general needs of other OBA deployments.
- Improve, extend, and/or otherwise adapt the UI's from onebusaway-nyc to meet the general needs of other OBA deployments.
Some likely examples of the types of changes referred to in the final 2 above items are the following:
- inclusion of real-time arrival predictions (NYC's UI's are just showing distance of the bus to the stop)
- the display of scheduled arrival times when real-time data is lacking
- the inclusion of explicit data and indications of schedule deviation
To include such features and meet the needs of a broad range of deployments likely requires making these new behaviors and others that currently exist (eg so-called "wrap-around" behavior) configurable/pluggable/etc.
For a full list of changes that are planned for the OBA RESTful APIs, please see the RESTful API Roadmap page.
One additional note: the UI's in the existing OneBusAway UI's, which are built using GWT, do not use the RESTful API. As such, the deprecation and migration described above can happen independently for the UI's and for the RESTful API's.
- Support the transition of the existing OBA API clients (eg native iPhone and Android applications) to use the SIRI API's for real-time information (but still use the OBA API for static/discovery functions). See the RESTful API Roadmap page for details.
- As part of the general move of modules from onebusaway-nyc to onebusaway, document all of the 'enterprise' functions that have been developed for the nyc project, including:
- distributed architecture for failover/high availability
- hot-swap of bundles for live automated/scheduled changes of bundle files
- bundle building and deployment UI's
- Publish the currently non-public scripts, programs, configurations, and documentation used in NYC to deploy OBA in a highly available manner using Amazon's AWS cloud-based infrastructure services. This depends on suitable refactoring of those artifacts so as not to compromise the security or stability of the NYC deployment.
In general: support the use of OneBusAway both with and without an existing CAD/AVL system.
One of the major additions of the onebusaway-nyc project is the so-called "Inference Engine" (aka "IE") -- a set of mathematical/probabilistic models and algorithms that transform fairly raw, noisy, incomplete, and often contradictory information directly from buses into a best guess as to what a given bus is actually doing. In the NYC case, this fulfills the role that a CAD/AVL system plays in the existing/traditional OneBusAway deployment use case.
Thus, the specific items would be:
- generalize the Inference Engine, as needed, to handle scenarios of data flows directly from individual buses that are different from NYC
- maintain support in the existing OneBusAway core for bulk real-time imports in standard (eg GTFS-realtime) and non-standard formats (as they currently exist, or as needed)
- Strip out of the core OBA codebase all methods, services, interfaces, modules, etc. that will not be used in support of the roadmap.
As with any good open source project, as much good, clear, concise documentation as is possible and necessary for people to:
- Understand what the project is/does
- Get started from a use/configuration/deployment perspective
- Get started from a development/hacking perspective