ConfiguringTheWebapp

Configuring the opentripplanner-api-webapp

There are a couple of files that are used to configure the opentripplanner-api-webapp before you run it. The default/example configuration provided in src/defaults/resources/ will be copied into ' src/main/resources/ ' during the build process, but at least data-sources.xml will need to be modified to match your configuration.

data-sources.xml

Add the following file to your source tree, or modify the example file that was copied to this location when and if you already built OTP:

opentripplanner-api-webapp/src/main/resources/data-sources.xml

The contents of the file should look like:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">



<bean id="graphBundle" class="org.opentripplanner.model.GraphBundle">

    <property name="path" value="/path/to/your/graph-bundle/goes/here" />

</bean>

The main thing to do here is change the path setting to match the directory of your serialized graph bundle that you produced with GraphBuilder.

application-context.xml

This file contains Spring IOC (dependency injection) configuration metadata, which describes how to assemble the api-webapp from various components. The details of how OTP performs path searches can be changed by changing the component classes specified in this file, as well as the values assigned to their attributes. When getting started with OTP, you should not need to modify the example file that is copied over from src/defaults/resources when OTP is built, but remember that these options are available for configuration later if you need them.

Create or edit the application-context configuration file at: opentripplanner-api-webapp/src/main/resources/org/opentripplanner/api/application-context.xml

It should look something like the following:

<import resource="classpath:org/opentripplanner/application-context.xml" />

<bean id="graphService" class="org.opentripplanner.routing.impl.GraphServiceImpl">
	<property name="bundle" ref="graphBundle" />
</bean>

<bean id="pathService" class="org.opentripplanner.routing.impl.ContractionPathServiceImpl">
	<property name="remainingWeightHeuristicFactory" ref="heuristicFactory" />
    <property name="firstPathTimeout" value="10.0" />
    <property name="multiPathTimeout" value="0.6" />
</bean>

<bean id="heuristicFactory" 
      class="org.opentripplanner.routing.impl.DefaultRemainingWeightHeuristicFactoryImpl">
	<!-- <constructor-arg ref="graphService" />  -->
</bean>

<bean id="patchService" class="org.opentripplanner.routing.impl.PatchServiceImpl">
</bean>

<bean id="pathServiceFactory" class="org.opentripplanner.routing.impl.SingletonPathServiceFactoryImpl">
	<property name="pathService" ref="pathService" />
</bean>

Basic configuration: Timeouts

Advanced configuration: Heuristic factory

Currently, the contractionPathService usually falls back on the A* routing algorithm, which in turn makes use of a remainingWeightHeuristic, a class that can provide a (conservative) estimate of remaining 'weight' or 'cost' to reach the destination (see [http://en.wikipedia.org/wiki/A*_search_algorithm]). The best heuristic for a particular search depends on the transportation modes as well as other user-specified options, and a RemainingWeightHeuristicFactory implementation carries out that choice. The DefaultRemainingWeightHeuristicImplementation simply always uses Euclidean distance, but others are available, such as the LBGRemainingWeightHeuristicImpl, which (when appropriate) will build a transit-specific heuristic by working backwards from the destination.