Table des matières

Rechercher sur le site

Open Journey Planner (OJP)

#AutoTranslate

Description rapide

Qu’est-ce que l’OJP?

L’abréviation a trois significations:

  1. La norme d’interface CEN/TS 17118 «Open API for Distributed Journey Planning», prévu par le règlement délégué (UE 2017/1926) a été déclarée contraignante pour les États membres de l’Union européenne.
  2. Le système backend de routage «Open Journey Planner» pour calculer des itinéraires avec les transports publics (TP), les trajets à pied et d’autres offres de mobilité.
  3. L’interface OJP, c’est-à-dire l’interface du système OJP qui correspond au standard OJP. Il s’agit essentiellement d’un standard XML avec un comportement Request/Response. Comme pour toutes les normes CEN, un profil est développé pour la Suisse précisant les éléments pris en charge et ceux qui ne le sont pas. Le profil est sûr ici.

Sur cette plate-forme Open Data, l’abréviation «OJP» est généralement utilisée pour le système «Open Journey Planner», sauf indication contraire.

Sur cette page, nous écrivons pour différencier la norme OJP (norme CEN), le système OJP (système de routage) et l’interface OJP.

Qui est impliqué?

Comme décrit ci-dessus, la norme OJP est proposée par le Comité européen de normalisation (CEN). Sur mandat de l’Office fédéral des transports (OFT), l’unité Tâches systémiques Information à la clientèle Plus (SKI+) contribue activement au développement de la norme OJP. La norme OJP est basée sur la norme Network Timetable Exchange (NeTEx) du CEN. Les modèles de données des deux normes mettent en œuvre le modèle de données de référence pour les transports publics en Europe, appelé Transmodel.

Le système OJP est développé par un prestataire de services externe de SKI+. Le système est basé sur un produit propriétaire du prestataire de services externe. Le système OJP peut être piloté avec le standard OJP.

L’interface OJP est basée sur le Travellors Realtime Information Advisory Standard (TRIAS) conforme à l’instruction 431 du Verband Deutscher Verkehrsunternehmen (VDV) à venir.

Une démonstration permettant de tester le système OJP en utilisant la norme OJP est disponible ici: Démo OJP

De plus amples informations sur l’évaluation de l’OJP en tant que standard sont disponibles dans le Rapport de l’OFT.

Pourquoi offre-t-elle Plate-forme Open Data?

Le standard OJP permet une interface ouverte et standardisée pour la «planification d’itinéraires répartie». Ainsi, différents systèmes peuvent collaborer selon ce standard développé au niveau européen pour proposer une planification d’itinéraires transfrontalière ou intégrant différentes modalités de transport, ou pour permettre de nouveaux services d’information innovants.

Le système OJP sert à remplir le mandat de l’OFT selon un routeur non discriminatoire et intermodal qui peut être piloté via une interface conforme au standard OJP. Le système OJP est prévu pour que ses services soient utilisés pour le développement d’applications destinées au consommateur final. Le contact direct avec la clientèle et ses données restent pour ces applications du consommateur final!

Il est important de comprendre que, malgré leur nom similaire, les routeurs et le standard sont deux choses fondamentalement indépendantes.

Remarque: Une description de la manière d’accéder aux API se trouve sûrement ici: Howto: Accès à nos API avec des clés d’API.

Accès à l’API

Remarque: Nous recommandons Page GitHub ou notre interface API pour voir quelques exemples pratiques.

Description métier

Quels services (points d’extrémité d’interfaces) la norme OJP propose-t-elle?

La norme OJP définit différents points d’extrémité d’interfaces (désignés ci-après uniquement par «services»). Dans la version 1,0 il s’agit de 7 «services clés» et dans la version 2,0, il s’agit de 9 «services clés». Ces services sont commandés par le système OJP.

Le système OJP prend en charge les sept services de la version 1,0 qui peuvent être demandés et connectés (LinkedServices, décrits ci-dessous dans la partie technique). Tri par importance:

  1. Situation personnelle: Vous souhaitez calculer un itinéraire avec votre famille avec différents moyens de transport?
    • Dans ce cas, tu as besoin du TripRequest
    • Fonction du service: Le système de desserte (chez nous, le système OJP) effectue un routage pour ce service.
    • Ce dont le service a besoin: Lorsque vous saisissez un point de départ et un point d’arrivée (chacun étant une coordonnée, une adresse, un point d’intérêt ou un arrêt), le système OJP calcule les trajets du point de départ au point d’arrivée. Différents modes supplémentaires peuvent être demandés avec ModesToCover. Les modes actuellement disponibles sont les suivants: transports publics; parcours à pied; vélo; voiture autonome; offres de partage (vélo, scooter électrique, autopartage).
    • Ce que le service retour apporte: Le routing comprend aussi bien un routing des transports publics (compte tenu des horaires actuels et des perturbations) qu’un routing du trafic individuel basé sur des cartes (p. ex. avec sa propre voiture), basé sur OpenStreetMap (OSM). Si vous le souhaitez, vous pouvez demander les itinéraires géographiques effectifs à l’aide du paramètre de sortie Link-Projection et une TurnDescription est généralement disponible pour les parcours à pied (navigation décrite verbalement).
    • Plus Précisions à ce service via le lien suivant: OJPTripRequest v1.0 ou OJPTripRequest v2.0
  2. Ta situation: Tu souhaites afficher à tes clients les arrêts et points d’intérêt situés à proximité?
    • Dans ce cas, tu as besoin du LocationInformationRequest
    • Ce que fait le service: Ce service détermine les endroits les plus proches.
    • Ce dont le service a besoin: Lorsque vous saisissez une coordonnée ou une adresse, le système OJP détermine les lieux appropriés via une recherche de périmètres.
    • Ce que le service offre: Les arrêts et points d’intérêt à proximité de l’endroit indiqué.
    • Vous trouverez de plus amples informations sur ce service au lien suivant: OJPLocationInformationRequest v1.0 ou OJPLocationInformationRequest v2.0
  3. Votre situation: Vous voulez un affichage des départs pour l’arrêt devant votre magasin?
    • Dans ce cas, tu as besoin du StopEventRequest
    • Ce que fait le service: Le service détermine les heures de départ et d’arrivée d’une halte ou d’un arrêt.
    • Ce dont le service a besoin: Un arrêt spécifique doit être indiqué lors de la saisie.
    • Ce que le service offre: Prochains départs/arrivées à un arrêt donné.
    • Vous trouverez de plus amples informations sur ce service au lien suivant: OJPStopEventRequest v1.0 ou OJPStopEventRequest v2.0
  4. Votre situation: Vous avez besoin de tous les arrêts compris dans le trajet calculé au préalable?
    • Dans ce cas, tu as besoin du TripInfoRequest
    • Ce que fait le service: Ce service détermine plus de détails sur un «Voyage» déjà calculé (voir TripRequest).
    • Ce dont le service a besoin: Le parcours préalablement déterminé doit être indiqué.
    • Ce que le service donne: détails sur un «Voyage» déjà calculé.
    • Vous trouverez de plus amples informations sur ce service au lien suivant: OJPTripInfoRequest v1.0 ou OJPTripInfoRequest v2.0
  5. Ta situation:Vous souhaitez connaître le prix prévu du trajet que vous souhaitez effectuer?
    • Dans ce cas, tu as besoin du FareRequest
    • Ce que fait le service: Détermine le coût probable d’un trajet remis à l’aide de l’infrastructure suisse de calcul des coûts des transports publics.
    • Ce dont le service a besoin: Le «Journey» déterminé précédemment doit être indiqué.
    • Ce que le service offre: Le calcul du prix des voyages, y compris les trajets à rabais et la prise en compte de l’abonnement demi-tarif («ADT»). Seules les demandes de prix en Suisse sont possibles. IMPORTANT: Les informations sur les prix sont données à titre indicatif. Le prix effectif n’est défini qu’au moment de la commande. Le nombre de demandes est également limité.
    • Vous trouverez de plus amples informations sur ce service au lien suivant: Bêta: Tarifs OJP
  6. Votre situation: Vous souhaitez planifier un voyage en Autriche et trouver des lieux de correspondance adaptés?
    • Dans ce cas, tu as besoin du ExchangePointRequest
    • Ce que fait le service: Fournit une liste d’arrêts qui peuvent être utilisés comme points de transition entre deux régions. La requête fait partie du calcul d’itinéraire distribué de la norme OJP. Les régions sont celles desservies par d’autres systèmes distribués.
    • Ce dont le service a besoin: Un lieu spécifique pour l’arrêt de passage avec des systèmes voisins doit être recherché ainsi que les paramètres correspondants, par exemple par le type de lieu (POI, arrêts, etc.).
    • Ce que le service donne: Soit les arrêts de transition pour le lieu consulté, soit tous les arrêts de transition pouvant être utilisés pour le calcul de l’itinéraire.
    • S’il vous plaît nous contacter pour l’utilisation de ces services.
  7. Ta situation: Tu souhaites calculer un itinéraire entre Berne et ta tante à Zurich et faire un arrêt intermédiaire à Olten avant?
    • Dans ce cas, tu as besoin du MultiPointTripRequest
    • Que fait le service? Dans le cadre de ce service, le système de desserte (chez nous, le système OJP) effectue un routage, tout comme le TripRequest.
    • Ce dont le service a besoin: Outre les points de départ et d’arrivée (chacun étant une coordonnée, une adresse, un point d’intérêt ou un arrêt) (comme TripRequest) requièrent des points intermédiaires qui doivent être explicitement inclus ou exclus.
    • Prestations du service: Même chose que dans TripRequest et Le routage comprend aussi bien un routage des transports publics (compte tenu des horaires actuels et des perturbations) qu’un routage du transport individuel basé sur des cartes (p. ex. avec sa propre voiture), basé sur OpenStreetMap (OSM). Si vous le souhaitez, vous pouvez demander les itinéraires géographiques effectifs à l’aide du paramètre de sortie Link-Projection et une TurnDescription est généralement disponible pour les parcours à pied (navigation décrite verbalement).
    • S’il vous plaît nous contacter pour l’utilisation de ces services.
  8. Ta situation: Tu as fait calculer un itinéraire il y a quelques jours. La date du voyage est arrivée et tu souhaites consulter les dernières informations?
    • Dans ce cas, tu as besoin du (à partir de la version 2,0) TripRefineRequest
    • Ce que fait le service: Mettre à jour un Trip déjà calculé. Il est important que la demande ne soit pas un nouveau calcul!
    • Ce dont le service a besoin: Un Trip existant avec contexte et paramètres. Les paramètres peuvent agir comme un filtre, par exemple en envoyant uniquement des résultats partiels ne contenant pas de niveaux.
    • Contenu du service: Le service met à jour le Trip avec les ajouts souhaités, le cas échéant. Important:
      • Il se peut que le service fournisse plusieurs Trips et pas (uniquement) celui demandé.
      • Lors de cette demande, il peut arriver que le Trip précédent «interrompt». Dans ce cas, le Trip doit être recalculé.
      • La réponse de la TripRefineRequest doit donc toujours être vérifiée!
    • Vous trouverez de plus amples informations sur ce service au lien suivant: OJPTripRefineRequest
  9. Ta situation: Tu dois prolonger l’arrêt intermédiaire que tu as prévu à Olten?
    • Dans ce cas, tu as besoin du (à partir de la version 2,0) TripChangeRequest
    • Fonction du service Permet de prolonger la durée d’arrêt à un arrêt intermédiaire le long d’un Trip et d’obtenir le tronçon précédent ou suivant. Les autres parties pourraient ainsi être recalculées.
    • Ce dont le service a besoin: D’une Leg existante et des adaptations souhaitées.
    • Ce que le service offre: Un voyage modifié en fonction de vos souhaits.
    • Pas d’autres détails sur ce service pour le moment.
  10. SysRequest:
    1. En plus des 7 ou 9 services de base, il est possible d’interroger l’état de l’OJP (Version/DateFormat/etc.).
    2. Vous trouverez de plus amples informations sur ce service au lien suivant: OJP Sysrequest

Quels sont les notions et concepts les plus importants à connaître?

Afin de pouvoir utiliser l’interface OJP, il faut assimiler les termes et concepts suivants.

  • StopPoint
    • Description: Un StopPoint est un arrêt le long d’un 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. Le StopPoint est attribué au StopPlace via un StopAssignment.
  • StopPlace
    • Description: Le StopPlace est la représentation physique d’un arrêt. La taille d’un StopPlace peut varier. Les très grands arrêts comme la gare de Berne ou la gare de Zurich comprennent plusieurs StopPlaces.
  • Journey, le «trajet»
    • Description: Transport de clients par un itinéraire défini, une relation définie selon l’horaire et un parcours de moyen de transport précis, à une heure et dans une direction définie. Il existe différents types de Journey, p. ex.: DatedJourney pour un trajet d’un moyen de transport à une date donnée.
  • Trip, le «voyage»
    • Description: Un «voyage» et donc une forme non spécifique de la course concrète. Un Trip se compose de Legs (voir ci-dessous).
  • Leg, le «voyage»
    • Description: Tronçon d’un Trip. Voici les différents types de Legs:
      • ContinuousLeg: Leg non lié à un horaire.
      • TimedLeg: Leg selon un horaire.
      • TransferLeg: Leg pour un lieu où s’effectue une correspondance.
  • Direction
    • Description: Toutes les lignes et tous les trajets ont une direction. Celle-ci aide en premier lieu les entreprises de transport dans leur planification et, le cas échéant, dans l’affichage d’une «station finale/destination». Il s’agit donc d’un «attribut artificiel» qui ne permet pas d’en déduire la signification.
  • Facility
    • Description: Une Facility est un élément disponible dans un «lieu» (p. ex. arrêt) ou sur un «service» (p. ex. véhicule). Il s’agit par exemple des toilettes en gare ou de la voiture-restaurant. Actuellement, elles sont reprises des offres dans HRDF (cf. Notes de circulation). Le mapping s’effectue conformément à l’. Notes2FacilitiesMappingFile.
  • Mode
    • Description: Les Modes sont des moyens de transport possibles. Les Modes autorisés sont les suivants:
      • ContinuousMode: Mode non dépendant d’un horaire.
      • IndividualModes: transport individuel.
      • PtMode: un PtMode est un Mode dans Public Transport.
      • TransferModes: Mode impliquant une correspondance
      • XXXRef: Ces éléments sont des références. En définitive, il s’agira d’identifiants génériques à l’échelle de la Suisse. Ceux-ci sont toutefois en cours d’élaboration. Il y aura ici une évolution.

Description technique

Accès à l’API

Pour utiliser l’API/l’interface, un jeton est nécessaire. Ce jeton peut être utilisé via le API Manager dans l’offre.

Tous les services pour la version 1,0 sont accessibles via POST avec l’URL https://api.opentransportdata.swiss/ojp2020 disponible.

Tous les services pour la version 2,0 sont accessibles via POST avec l’URL https://api.opentransportdata.swiss/ojp20 disponible.

Vous pouvez utiliser l’interface OJP 2,0 essayer ici https://opentdatach.github.io/api-explorer/ojp2.0/

Fonctionnement de base de l’API

Requêtes simples

L’interface OJP correspond plus à une interface SOAP XML classique qu’à une interface REST. Tous les accès ont lieu via le point d’extrémité mentionné.

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

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

Les services décrits ci-dessus peuvent être distingués par les requêtes correspondantes dans l’élément ServiceRequest. Dans cet exemple, nous présentons un LocationInformationRequest désactivée.

Il convient de noter qu’en tant que RequestorRef, ils fournissent une indication unique. Il s’agit d’identifier l’auteur de la demande. L’indication doit comporter le suffixe «_test«, «_int” ou «_prod» afin que nous sachions de quel environnement l’accès a été effectué lors d’analyses et de demandes d’assistance ultérieures.

<?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>SomeAptlyNamedTransportCompany_int</RequestorRef>
			<ojp:OJPLocationInformationRequest>
				<!-- eigentlicher Request -->
			</ojp:OJPLocationInformationRequest>
		</ServiceRequest>
	</OJPRequest>
</OJP>

Plusieurs requêtes dans un message

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

Attention: les réponses ne sont pas triées dans l’ordre des requêtes soumises, mais selon l’ordre dans le fichier XSD standard. Il est donc extrêmement important, pour de telles requêtes, que les MessageIdentifiers soient définis par requête afin que la réponse puisse ensuite être extraite. L’ordre standard est (version 1,0):

  • ExchangePointsRequest
  • FareRequest
  • LocationInformationRequest
  • MultiPointRequest
  • StopEventRequest
  • TripInfoRequest
  • TripRequest

En cas de problèmes liés à la gestion des interfaces, il convient de consulter cette page: OJP – Meilleures pratiques

Restrictions et informations complémentaires

Restrictions

  • Plusieurs 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.

Informations complémentaires