Technical Efforts to Provide the EU-Spirit Service

In general, every operator — regardless of the algorithms he uses – can participate in this open service system. Any updates of the time schedules in the local systems are automatically available for the EU-Spirit system which reduces the maintenance costs and improves the accuracy of the system and the information it provides.

Passive Server
Each provider of the EU-Spirit travel planning rings needs to provide a passive server. The passive server is a travel planning system which is able to take a SOAP/XML request as defined by the EU-Spirit API, compute the appropriate result and deliver it back to the calling programme.

The EU-Spirit API consists of five functions for different purposes. They are briefly described in the following, a detailed description can be found in the EU-Spirit project documentation.

  • Locations are called by the RODI in order to find matching locations for a given user input.
  • AllTransistions is called by RCC for retrieving a list of all transition points defined in this system.
  • Transitions is called by the RCC for getting a short list of optimal transition points for a given start-destination relation.
  • Connections is called by the RCC in order to compute complete itineraries between given start and destination locations.
  • PartialConnections is called by the RCC in order to compute partial itineraries between given start and destination locations.
  • RefineConnections can be used to add additional information to a computed itinerary, e.g. fare information.
  • Capabilities can be used to get the capabilities of a passive server
  • Usage can be used to get usage values of a passive server
  • Multi is a function, which contains several of the above mentioned requests.

All nine functions have to be implemented properly in the passive server. Capabilites, Usage, and RefineConnections are currently not used and can therefore be implemented only as a dummy.

Active Server
The active server provides access to the EU-Spirit travel planning system. It is usually a web based application which converts the user input into an appropriate EU-Spirit API request. Those are sent to the RODI or RCC respectively. The active server must be able to initiate Locations calls to the RODI and Connections calls to the RCC; the active server does not communicate directly with the passive servers. Nevertheless, it is possible to have an intelligent active server which passes only the non local requests to the EU-Spirit ring.

Meta data
The data of each passive server represents a transport network. In order to connect this network correctly with the rest of the ring, meta data has to be generated. The most important type of meta data (and the only one discussed here) are the transition points. The purpose of transition points is to connect two transport networks. Therefore, a transition point resides always in at least two systems. In order to avoid inconsistencies, all transition points must have a unique ID.