LargeGraphs

Large and Long Distance Graphs

OpenTripPlanner has been developed and tested mostly using data sets representing a single city or urban area. Many of the default settings are more suited for data sets of this size. It is certainly possible to combine several feeds and make a large regional graph, but search speed and memory use may suffer. Don't hestitate to try: we appreciate feedback on new configurations. This page will be used to collect configuration changes and other issues specific to large graphs.

Multi-path Timeouts

Sometimes the first itinerary is easy to find, but the second or subsequent itineraries are more difficult. Perhaps they don't exist at all, and the router has to do quite a bit of work to discover that fact. This is especially true in very large graphs. It is preferable to return several itineraries to the user, but maybe all you really need is one. You can decide to tolerate smaller numbers of itineraries in exchange for faster response times by specifying timeout values in your application-context.

For example, if you are using the RetryingPathServiceImpl, you could use the following config xml:

<bean id="pathService" class="org.opentripplanner.routing.impl.RetryingPathServiceImpl">
    <property name="firstPathTimeout" value="10.0" />
    <property name="multiPathTimeout" value="1.0" />
</bean>

This will take up to 10 seconds to find the first itinerary, but once an itinerary has been found it will bail out of the search if more than 1 second has elapsed.

Here is a similar snippet for the RAPTOR path service:

<bean id="pathService" class="org.opentripplanner.routing.impl.raptor.Raptor">
    <property name="multiPathTimeout" value="1.0" />
</bean>

The MaxTransfers Query Parameter

The router constrains the number of transit vehicles boarded. By default, the number of transfers is limited to 2, so up to three vehicles are used in an itinerary. This may not be enough for a complicated intercity path, so if your graph contains origin-destination pairs that may require more than three vehicles to connect efficiently you will want to increase this value using the maxTransfers query parameter. Otherwise the router may spend a great deal of time examining every combination of routes looking for a non-existant 3-vehicle option. Note that there is a hard-coded upper limit on the number of transfers at the top of org.opentripplanner.routing.core.RoutingRequest (CLAMP_TRANSFERS=6).