The initial steps for setting up a development environments must follow the instructions found in OpenTripPlanner wiki:

• OpenTripPlanner installation.
• Getting Started with Eclipse

Take in account when following this instructions, the repository that has to be cloned differs. Our respository's URI is: https://github.com/solidrockit/OpenMove.git. Remember to use this instead of OpenTripPlanner's git repository.

After setting up a development environment with Eclipse for OpenMove, a graph must be generated before starting a OpenMove. We need at least 2 OpenMove servers running to test distributed rote search.

In this example we will have two OpenMove servers. Each server will have different GTFS data depending on the region covered by each of them:

• Server 1: Araba/Álava region
• Server 2: Gipuzkoa region

Of course, this is just an example. You can use any pair of region to use in OpenMove.

First, we need to download transit data for each server.

For server 1 at least GTFS data of Tuvisa and Euskotren Tranbia will be downloaded. The file is available at GeoEuskadi (Thanks to Moveuskadi):

• Tuvisa-Euskotren Tranbia

For server2 we will download GTFS data from DBus and Lurraldebus Pesa agencies. These files are also available at GeoEuskadi (Thanks to Moveuskadi):

• dBUS
• Lurraldebus Pesa

This GTFS files are only a subset of GTFS files for each region and cover only the following cities: Araba/Álava region:

• Vitoria-Gasteiz Gipuzkoa region:
• Donostia/San Sebastián
• Debagoiena district

However, this GTFS files should be enough to test OpenMove's distributed capabilities. Optionally, other GTFS files can also be downloaded to improve the graph's coverage of both regions. See OptionalGTFSFiles

Before starting the server, the graph with transit data must be generated. The instructions below are based on GraphBuilder instructions in OpenTripPlanner's wiki.

The graph builder needs some configuration files in order to build the graph:

• Shared vertex configuration file: Used by OpenMove to identify nodes (stations) shared by two neighbour OpenMove servers.
• Graph builder configuration file: Used by opentripplanner-graph-builder to build the graph

OpenMove requires a list of shared vertex, which identify the stops shared by each pair of OpenMove servers that will be used as transfer points for routes covering both servers. This XML file stores data about all neighbour OpenMove server that our OpenMove server will be working together with and the stops shared between them.

The content of these configuration files will change from server to server. In the example, the configuration should look similar to this:

• OpenMove server for Araba/Álava region:
  • Neighbour server: Gipuzkoa OpenMove Server
  • Shared vertex (shared stop): Vitoria-Gasteiz bus station (located in Araba/Álava)
• OpenMove server for Gipuzkoa region:
  • Neighbour server: Araba/Álava region
  • Shared vertex (shared stop): Vitoria-Gasteiz bus station (located in Araba/Álava)

Fields for each entity:

• Server:

  • globalId: Global identificator for the neighbouring server. This identificator will be unique for each OpenMove server deployed.
  • id: Identificator for the neighbouring server. This identificator will be unique for each neighbouring OpenMove server which are neighbour of each deployment.
  • serviceUrl: URL for neighbouring server frontend
  • url: Neighbouring server's API's endpoint

• Shared vertex (shared stop):

  • code: Stop's code (copy from GTFS file)
  • id: Stop's identificator (copy from GTFS file)
  • lat: Stop's latitude (copy from GTFS file)
  • lon: Stop's longitude (copy from GTFS file)
  • localStop: Specifies if the shared vertex in geographically located in the area covered by the server. If that's the case, the stop should have the parameter localStop="localStop". If not, this parameter should be ignored.
  • name: Stop's name (copy from GTFS file)

The file of shared vertex for Araba/Álava OpenMove server should look similar to:

<?xml version="1.0" encoding="UTF-8"?>
<servers>
	<server globalId="SS" id="SS" name="Gipuzkoa" serviceUrl="http://192.168.111.173:8080" url="http://192.168.111.173:8080/opentripplanner-webapp">
	<nodes>
		<node code="" id="1415" lat="42.8497850354" localStop="localStop" lon="-2.66607905601" name="Estacion Vitoria, Los Herran Vitoria - Gasteiz" />
		</nodes>
	</server>
</servers>

The file of shared vertex for Gipuzkoa OpenMove server should be similar to:

<?xml version="1.0" encoding="UTF-8"?>
<servers>
	<server globalId="SS" id="SS" name="Gipuzkoa" serviceUrl="http://192.168.111.173:8080" url="http://192.168.111.173:8080/opentripplanner-webapp">
	<nodes>
		<node code="" id="1415" lat="42.8497850354" localStop="localStop" lon="-2.66607905601" name="Estacion Vitoria, Los Herran Vitoria - Gasteiz" />
		</nodes>
	</server>
</servers>

TODO

We have some configuration files with sample data. The paths in this files must be changed before running the opentripplaner-build-graph module:

• Line 30: Path to OpenStreetMap cache
• Line 49: Path to OpenTripPlanner graph to be generated.
• Line 40: Replace {graphPath} with path to the generated graph (same as in line 49).

There are several configuration files stored in opentripplanner-graph-builder/graph_config:

• graph_vitoriagasteiz.xml: Configuration files to generate graph with Vitoria-Gasteiz transit data.
• local_gtfs.xml: Configuration files to generate a graph based on custom GTFS file. This file is stored locally and its path must be changed in line 14. Several ZIP files with GTFS data are available in Owncloud.
• araba_gtfs_config.xml: Configuration file with local GTFS files with transit data in the province of Alava. The GTFS files can be downloaded from Owncloud and paths in the XML have to be reviewed.
• bizkaia_gtfs_config.xml: Configuration file with local GTFS files with transit data in the province of Bizkaia. The GTFS files can be downloaded from Owncloud and paths in the XML have to be reviewed.
• gipuzkoa_gtfs_config.xml: Configuration file with local GTFS files with transit data in the province of Gipuzkoa. The GTFS files can be downloaded from Owncloud and paths in the XML have to be reviewed.

Running "opentripplanner-graph-builder" can be memory consuming, specially in case of large graphs (gipuzkoa_gtfs_config.xml and bizkaia_gtfs_config.xml). It is recommended to set a "large" amount of memory for the JVM when running the graph builder.

To do so, go to Running Configurations in Eclipse, and choose "Arguments" tab in opentripplanner-graph-builder run configuration and add "-Xmx1500m" to VM arguments field.

Before starting the server the webapp has to be configured to indicate the location of the generated graph. Instructions for this configuration are available in OpenTripPlanner wiki.

The path in this configuration file must be the one specified in line 49 of opentripplanner-build-graph configuration module. Example:

<?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">
		<property name="path" value="/home/user/otp/graph-bundle" />
        <!-- other optional properties for multiple graph registration -->
        <!-- 
        <property name="defaultRouterId" value="pdx" />
        <property name="autoRegister">
          <list>
            <value>nyc</value>
            <value>seattle</value>
          </list>
        </property>
        -->
	</bean>
	
</beans>

Similar to opentripplanner-graph-builder, dealing with large graphs can be memory consuming. If new memory settings are not set, a Java OutOfMemory exception may appear. To avoid it, set a new memory limit for JVM by openning Run Configurations in Eclipse and adding "-Xmx1500m" to "VM arguments" field in "Arguments tab". 1500m especifies 1500MB as new memory for the JVM. Similarly, other memory sizes can be chosen.

The usual steps to solve this issue are:

• Select all projects and click on: Project > Clean.
• Right click on server and click on "Clean Tomcat Work Directory".
• Right click on server and click on "Clean".
• Right click on projects and click on: Maven > Update project.