Skip to content

DevelopersGuide

Jump to bottom Edit New page
Nicholas Bergson-Shilcock edited this page Jul 19, 2011 · 35 revisions

Developers Guide

[TOC()]

This page contains developer-centric information about the OpenTripPlanner project.

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.

  • opentripplanner-api-extended Exposes a RESTful API used by the optional system map view in the webapp. Note: This module is experimental, and both its implementation and the interface it exposes are subject to change substantially.

Tickets and checkins

All checkins should reference a specific ticket (decided in #175). For example, "Fixes #9999 (spaceships aren't support by routing engine)". If no ticket exists for the feature or bug your code implements or fixes, you should create a new ticket prior to checking in.

We use the RepositoryHookSystem plugin to automatically update tickets on checkin. If your commit message includes the text "fixes #123", it will automatically append your message as a comment on the ticket and close it. If you include "updates #123", your message will be appended to the ticket but it will remain open.

Synonyms for closing tickets (append comment and close): close, closed, closes, fix, fixed, fixes

Synonyms for updating ticket (append comment and leave open): addresses, re, references, refs, see, update, updates

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.

  • Submit patches. If you're not yet a committer, please attach patches to the relevant Trac ticket.

  • 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).

Add a custom footer
Add a custom sidebar
Clone this wiki locally