Skip to content
LoginRegister
DEENFRIT
Home
Plateforme open data pour la mobilité en Suisse
  2. Cookbook
  3. Open Journey Planner (OJP)

Open Journey Planner (OJP)

 

Introduction

Par le Open Journey Planner (OJP) les CFF établissent une interface de planification distribuée de trajets. Il s’agit d’une interface « open » et standardisée selon des spécifications européennes. Elle permettra à différents systèmes d’échanger des informations entre eux afin de pouvoir planifier des trajets transfrontaliers ou utilisant divers moyens de transport, ou afin de pouvoir offrir de nouveaux services innovateurs. L’interface a été développée à partir du système allemand TRIAS.

A long terme, OJP va être le seul système mis à disposition par les CFF.

Description spécialisée

Glossaire

  • OJP: désigne aussi bien le protocole que le système utilisé.
  • StopPoint: un StopPoint est un arrêt requis du point de vue de l’horaire. Il peut s’agir d’une halte, d’une voie, d’un secteur, d’une bordure d’arrêt ou d’un élément dynamique. En général, il est trop spécifique pour la recherche.
  • StopPlace: le StopPlace correspond à la halte. Les très grands complexes tels que la gare de Berne ou celle de Zurich comportent plusieurs StopPlaces.
  • Trip: trajet
  • Leg: tronçon d’un Trip.
  • DatedJourney: convoi d’un moyen de transport à une date précise.
  • Direction: toutes les lignes et tous les convois ont une direction. Il est important de noter que cet attribut est artificiel. Les opérateurs assignes ce valeur et c’est impossible de le déduire.
  • Facility: une Facility est un élément disponible dans un «lieu» (p. ex. halte) ou sur un «service» (p. ex. véhicule).
  • Mode: les Modes sont les moyens de transport possibles.
    • ContinuousMode: Mode non lié à un horaire.
    • IndividualModes: transports individuels.
    • XXXRef: références. Dans la version finale, il s’agira d’identifiants génériques à l’échelon de la Suisse, mais ceux-ci sont encore en cours d’élaboration. Les éléments fournis ici sont donc susceptibles d’évoluer.
    • PtMode: un PtMode est un Mode dans Public Transport.
    • TransferModes: Mode impliquant une correspondance.

Notions importantes

Un Trip se compose de Legs. Voici les différents types de Legs:

  • ContinuousLeg: Leg non lié à un horaire.
  • TimedLeg: Leg lié à un horaire.
  • TransferLeg: Leg pour un lieu où s’effectue une correspondance.

 

Restrictions importantes

  • Actuellement, seuls les TP de Suisse sont pris en compte.
  • Certains modes ne sont pas encore disponibles.
  • Les informations en temps réel ne sont disponibles que lorsque nous avons reçu ces informations et pouvons les obtenir via CUS.
  • Les informations relatives aux dérangements ne sont pas encore disponibles.

 

Explorateur de l’API

Explorateur de l’API

Accès à l’API

Comme pour toutes les API des CFF, un jeton est nécessaire. Pour l’obtenir, visiter le portail pour les dévélopeurs.

Tous les Services sont disponibles par POST au moyen de l’URL  https://api.opentransportdata.swiss/ojp2020.

Deux en-têtes doivent être définis:

Content-Type: application/xml
Authorization: Bearer <der Key>

La clé de travail actuelle est:

57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1

Fonctionnement d’Open Journey Planner

OJP fonctionne comme TRIAS (VDV 431).

L’interface TRIAS d’opentransportdata.swiss sera «augmentée» au moment du déploiement d’OJP. C’est-à-dire qu’elle sera capable de calculer des itinéraires.

Requests pertinentes:

D’autres API sont prévues à moyen terme (p. ex. FareRequest), ainsi que des améliorations: informations sur les dérangements, informations en lien avec la LHand.

Essentiellement au standard XML avec un comportement Request/Response, elles seront basées sur la norme européenne OJP. Comme pour toutes les normes du CEN, un profil sera développé spécifiquement pour la Suisse (précisant les éléments supportés et ceux non pris en charge).

Tous les accès auront lieu via un point d’accès. Les services sont définis dans l’element ServiceRequest. Ce n’est pas de REST classic.

<?xml version="1.0" encoding="UTF-8"?>
<OJP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.siri.org.uk/siri" version="1.0" xmlns:ojp="http://www.vdv.de/ojp" xsi:schemaLocation="http://www.siri.org.uk/siri ../ojp-xsd-v1.0/OJP.xsd">
	<OJPRequest>
		<ServiceRequest>
			<RequestTimestamp>2020-01-09T08:00:00Z</RequestTimestamp>
			<RequestorRef>IRMA</RequestorRef>
			<ojp:OJPLocationInformationRequest>
				<!-- eigentlicher Request -->
			</ojp:OJPLocationInformationRequest>
		</ServiceRequest>
	</OJPRequest>
</OJP>

En tant que RequestorRef, veuillez utiliser une indication explicite. Celle-ci doit comporter le suffixe «_test», «_int» ou «_prod» afin que nous sachions quel environnement est à l’origine de l’accès du côté du Requestor.

Plusieurs Requests dans un seul message

Il est possible d’émettre autant d’OJPXXXRequests que l’on souhaite au sein d’une même ServiceRequest. Ces requêtes ne doivent pas nécessairement être du même type.

Attention: les réponses ne sont pas fournies selon l’ordre des Requests, mais en fonction de la séquence dans l’élément XSD.

Il est par conséquent très important, pour de telles requêtes, que les MessageIdentifiers soient définis par Request afin de permettre l’extraction de la réponse.

 

Informations supplémentaires