DevelopersGuide

Developers Guide

Note: This page will ultimately be a full developers guide with information necessary to help developers new to OpenTripPlanner get up and running as easily as possible. For now it's mostly a stub.

Getting the code and installation

See the installation instructions for details on how to check out the code and run the tests.

Project modules

The OpenTripPlanner project is composed of a number of different modules. These are:

• opentripplanner-routing. The core routing engine. This includes the vertex and edge classes and interfaces that compose the graph structure and the algorithms used for finding the shortest path in the graph.

• opentripplanner-graph-builder. This is a command-line utility used for turning raw transit and street data into a compiled graph that can be routed on. See the GraphBuilder page for more details.

• opentripplanner-api-webapp A web application that exposes a RESTful API for making requests to the trip planner. This module requires the opentripplanner-routing module as well as a graph object compiled by the opentripplanner-graph-builder module.

• opentripplanner-webapp. A front-end web application and user interface that communicates with the opentripplanner-api-webapp. The code is based on TriMet's existing trip planner UI. Future plans call for a (set of) MobileDevice ui(s).

• opentripplanner-gui. A graphical interface for visualizing graph data compiled by the opentripplanner-graph-builder module. This is mostly helpful for troubleshooting and debugging purposes, as it allows you to quickly explore a graph.

• opentripplanner-integration. A set of integration sets useful used both for testing that the entire system works together and for getting started with the project quickly. The tests will automatically generate a compiled graph using GTFS and OSM data for Portland and run the API and trip planner web app so you can try out planning trips.

Comments & code documentation

As a matter of policy, all new methods, classes, and fields should include comments explaining what they are for and any other pertinent information. For Java code, the comments should use the JavaDoc conventions. When documenting fields with getters and setters, the comments should go with the getter.

Code style

OpenTripPlanner uses the same code formatting and style as used by both the GeoTools and GeoServer projects. It's a minor variant of the Sun coding convention. Notably, we do not use tabs and we allow for lines up to 100 characters wide.

If you use Eclipse, you should do the following to make sure your code is automatically formatted correctly:

1. Download the Eclipse profile from GeoTools.

2. Open the project Properties (right-click on the project directory in Eclipse and select Properties or choose Project -> Properties).

3. Select Java, then Code Style, and finally Formatter.

4. Check the Enable project specific settings checkbox.

5. Click Import..., select the formatter.xml file you downloaded above, and click Open.

6. Click OK to close the Properties window.

Contributing to the project

OpenTripPlanner is a community based open source project, and we welcome all who wish to contribute. There are several ways to get involved:

• Create a Trac account. This will let you create tickets and edit the wiki.

• Join the developer mailing list (and the commits list, too, if you like).

• Fix typos and improve the documentation on the wiki.

• File a bug or new feature request.

• Become a committer. If you'd like to contribute code to the project beyond the occasional patch, you can request commit rights for the project. Before doing so, you should:

1. Make yourself known to the rest of the community by introducing yourself on the mailing list, hanging out in the IRC channel, and/or joining one of our weekly conference calls.

2. Submit at least one patch to the mailing list for review. It doesn't have to be perfect, and it doesn't have be huge, but it should do something useful (e.g., fix a bug, add a new feature, make the code faster/more efficient, etc).