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. Though default/example configuration files provided in src/defaults/resources/ will be copied into src/main/resources/ during the build process, at least data-sources.xml will need to be modified before you start the api-webapp.

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:

<?xml version="1.0" encoding="UTF-8"?>
<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">

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

	<!-- specify a GraphService, configuring the path to the serialized Graphs -->
	<bean id="graphService" class="org.opentripplanner.routing.impl.GraphServiceImpl">
		<!-- the placeholder {} in the path will be replaced with the routerId -->
		<property name="path" value="/var/otp/graphs/{}/" />
	</bean>
	
</beans>

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 properties. When getting started with OTP, you should not need to modify the example file that will be copied over from src/defaults/resources when OTP is built, but remember that these options are available for configuration later if you need them.

You can 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:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx" xmlns:sec="http://www.springframework.org/schema/security"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
           http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
           http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.xsd">

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

    <context:component-scan base-package="org.opentripplanner.analyst"/>
    <context:component-scan base-package="org.opentripplanner.api"/>

    <bean id="pathService" class="org.opentripplanner.routing.impl.RetryingPathServiceImpl">
        <property name="firstPathTimeout" value="10.0" />
        <property name="multiPathTimeout" value="1.0" />
    </bean>
 
  <bean id="heuristicFactory" class="org.opentripplanner.routing.impl.DefaultRemainingWeightHeuristicFactoryImpl"/>
  <bean id="sptService" class="org.opentripplanner.routing.algorithm.GenericAStar"/>
  <bean id="jsonpCallbackFilter" class="org.opentripplanner.jsonp.JsonpCallbackFilter" />

</beans>

Basic configuration: Timeouts

Path searches can take quite a long time to complete, especially certain problematic cases that have yet to be optimized. Often a first itinerary is found quickly, but one of the later sub-searches is very slow and delays the response.

By changing properties of the ContractionPathServiceImpl, you can set timeouts to avoid tying up server resources on pointless searches and assure that your end-users receive a timely response. When a search times out, a WARN level log entry is made with information that can help us identify problematic searches and improve our routing methods.

The available timeout properties are:

timeout : Specifies a simple timeout. Searching is aborted after this many seconds and any paths found are returned. Internally, it just sets firstPathTimeout and multiPathTimeout to the same value -- you should only specify this if you do not specify a first/multi timeout pair, and vice versa.
firstPathTimeout : Give up on searching for the first itinerary after this many seconds have elapsed. A negative or zero value means search forever.
multiPathTimeout : Stop searching for the N-1 additional itineraries (beyond the first one) after this many seconds have elapsed, relative to the beginning of the search for the first itinerary, and return all itineraries that have been found. A negative or zero value means search forever. Setting this lower than the firstPathTimeout will avoid searching for additional itineraries when finding the first itinerary takes a long time. This helps keep overall response time down while assuring that the end user will get at least one response.

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 this explanation). 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.

Provide feedback

Saved searches