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)

État: janvier 2024. Tu trouveras des informations sur les adaptations continues dans notre changelog.

Arrière-plan

Qu’est-ce que l’OJP?

Cette abréviation a trois significations:

  1. La norme d’interface CEN/TS 17118 «Open API for Distributed Journey Planning», qui a été déclarée obligatoire pour les États membres de l’Union européenne dans le règlement délégué (UE 2017/1926).
  2. Le système dorsal de routage “Open Journey Planner” pour le calcul d’itinéraires avec les transports publics (TP), les chemins pédestres et d’autres offres de mobilité.
  3. L’interface OJP, c’est-à-dire l’interface du système OJP correspondant au standard OJP. Elle est à la base un standard XML avec un comportement Request/Response. 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). Le profil est lié ici.

Sur cette plateforme de données ouvertes, sauf indication contraire, l’abréviation “OJP” est généralement utilisée pour désigner le système “Open Journey Planner”.

Sur cette page, nous écrivons pour distinguer le standard 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 promue par le Comité européen de normalisation (CEN). Le bureau Tâches système Information à la clientèle Plus (SKI+) participe activement au développement du standard OJP sur mandat de l’Office fédéral des transports (OFT). Le standard OJP est basé sur le standard CEN Network Timetable Exchange (NeTEx). Les modèles de données des deux normes implémentent à leur tour 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 à la 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), qui suit la directive 431 de l’Association des entreprises de transport allemandes (Verband Deutscher Verkehrsunternehmen, VDV).

Une démo pour tester le système OJP en utilisant le standard OJP se trouve ici : OJP Demo

Tu trouveras plus d’informations sur l’évaluation d’OJP en tant que standard dans le rapport de l’OFT (en Allemand).

Pourquoi la plate-forme Open Data propose-t-elle cela?

La norme OJP permet une interface ouverte et standardisée pour la “planification d’itinéraires distribués”. Ainsi, différents systèmes peuvent coopérer selon cette norme développée au niveau européen pour offrir une planification de voyage 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 d’un routeur non discriminatoire et intermodal, qui peut être piloté par une interface conforme au standard OJP. Le système OJP est conçu pour que ses services soient utilisés pour le développement d’applications destinées aux clients finaux. Le contact direct avec les clients et leurs données restent dans ces applications pour clients finaux!

Il est important de comprendre que, malgré leur appellation similaire, le routeur et la norme sont deux choses fondamentalement indépendantes.

Comment accéder aux données/interfaces?

Données

Comme décrit précédemment, OJP est un système/interface standard, il n’y a donc pas de téléchargement de fichier.

Nous recommandons toutefois le lien de la page GitHub ou notre interface API pour voir une paire d’exemples pratiques.

Interfaces

Détails sur l’API OJP: https://opentransportdata.swiss/fr/dataset/ojp2020 (productif depuis 2020)

Détails sur l’API OJP (2.0) : https://opentransportdata.swiss/de/dataset/ojp2-0 (en production, encore en construction)

Détails sur l’API OJP-Fare: https://opentransportdata.swiss/fr/dataset/ojpfare

Description spécifique

Attention : la description suivante se réfère à OJP2020 (donc à OJP-API v1.0). Pour travailler avec l’API OJP 2.0, voir https://opentransportdata.swiss/de/cookbook/ojp2entwicklung/.

Quels sont les services (points finaux d’interface) proposés par la norme OJP?

La norme OJP définit différents points finaux d’interface (désignés ci-après par le terme “services”). Dans la version 1.0, il s’agit de 7 “services de base” et dans la version 2.0, de 9 “services de base”. Ces services sont desservis par le système OJP.

Le système OJP prend en charge tous les 7 services de la version 1.0 qui peuvent être consultés et liés (LinkedServices, décrits dans la section technique ci-dessous). Classés par ordre d’importance:

  1. Ta situation: tu souhaites calculer un itinéraire avec ta famille en utilisant différents moyens de transport?
    • Ensuite, tu as besoin du TripRequest
    • Ce que fait le service: dans le cadre de ce service, le système de desserte (chez nous, le système OJP) effectue un routage.
    • Ce dont le service a besoin: lors de la saisie d’un point de départ et d’un point d’arrivée (respectivement coordonnées, adresse, point d’intérêt ou arrêt), le système OJP calcule des liaisons du point de départ au point d’arrivée. Différents modes peuvent être demandés en plus avec ModesToCover. Actuellement, les modes suivants sont disponibles : transports publics ; marche à pied ; vélo ; voiture autotractée ; offres de partage (vélo, scooter électrique, autopartage).
    • Ce que le service donne: Le routing comprend aussi bien un routing des transports publics (en tenant compte des horaires actuels et des perturbations) qu’un routing du trafic individuel basé sur une carte (par exemple avec sa propre voiture) sur la base d’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 pour les itinéraires pédestres, une TurnDescription est généralement disponible (navigation décrite verbalement).
    • Plus de détails sur ce service en cliquant sur le lien suivant : OJPTripRequest
  2. Ta situation: tu souhaites indiquer à tes clients les arrêts et les points d’intérêt à proximité de chez toi?
    • Ensuite, tu as besoin de la LocationInformationRequest
    • Ce que fait le service: Ce service détermine les lieux les plus proches.
    • Ce dont le service a besoin: Lors de l’entrée d’une coordonnée ou d’une adresse, le système OJP détermine les lieux appropriés grâce à une recherche de proximité.
    • Ce que le service donne: Les arrêts et les points d’intérêt à proximité du lieu indiqué.
    • Plus de détails sur ce service sous le lien suivant : OJPLocationInformationRequest
  3. Ta situation: tu veux un moniteur de départ pour l’arrêt de bus devant ton magasin?
    • Ensuite, tu as besoin du StopEventRequest
    • Ce que fait le service: Le service détermine les heures de départ et d’arrivée d’un arrêt.
    • Ce dont le service a besoin: Lors de la saisie, un arrêt spécifique doit être indiqué.
    • Ce que le service donne: Les prochains départs / arrivées d’un arrêt donné.
    • Plus de détails sur ce service en cliquant sur le lien suivant : OJPStopEventRequest
  4. Ta situation: tu as besoin de tous les points d’arrêt le long du trajet calculé précédemment?
    • Ensuite, tu as besoin de la TripInfoRequest
    • Ce que fait le service: ce service détermine d’autres détails sur un “Journey” (trajet) déjà calculé (cf. TripRequest).
    • Ce dont le service a besoin: Le Journey déterminé auparavant doit être donné avec.
    • Ce que le service donne: Détails d’un “Journey” (trajet) déjà calculé.
    • Plus de détails sur ce service en cliquant sur le lien suivant : OJPTripInfoRequest
  5. Ta situation: tu souhaites savoir combien coûtera probablement le trajet que tu as demandé?
    • Ensuite, tu as besoin du FareRequest
    • Ce que fait le service: détermine les coûts prévisibles d’un trajet transmis à l’aide de l’infrastructure de calcul des coûts des transports publics en Suisse.
    • Ce dont le service a besoin: Le “Journey” (trajet) déterminé auparavant doit être fourni.
    • Ce que le service donne: Le calcul du prix des voyages, y compris les voyages à prix réduits et la prise en compte de l’abonnement demi-tarif (“HTA”). Seules les demandes de prix en Suisse sont possibles. IMPORTANT : L’information sur les prix n’est pas contraignante. Le prix effectif n’est défini qu’au moment de la commande. Le nombre de demandes est également limité.
    • Plus de détails sur ce service en cliquant sur le lien suivant: Beta: OJP Fares
  6. Ta situation: tu souhaites planifier un voyage en Autriche et trouver des points de correspondance appropriés?
    • Ensuite, tu as besoin de l’ExchangePointRequest
    • Ce que fait le service: fournit une liste d’arrêts qui peuvent être utilisés comme points de passage entre deux régions. La requête fait partie du calcul d’itinéraires distribués du standard OJP. Les régions sont celles qui sont desservies par d’autres systèmes répartis.
    • Ce dont le service a besoin: un lieu spécifique pour lequel des arrêts de transition vers des systèmes voisins doivent être recherchés, ainsi que des paramètres correspondants, par exemple sur le type de lieu (POI, arrêt, etc.).
    • Ce que le service donne: soit les arrêts de transition pour le lieu demandé, soit tous les arrêts de transition qui peuvent être utilisés pour le calcul de l’itinéraire.
    • Pas de détails supplémentaires sur ce service pour l’instant.
  7. Ta situation: tu souhaites calculer un itinéraire pour te rendre de Berne chez ta tante à Zurich et faire une halte à Olten avant de partir?
    • Ensuite, tu as besoin du MultiPointTripRequest
    • Ce que fait le service: pour ce service, le système qui le sert (dans notre cas, le système OJP) effectue un routage, tout comme le TripRequest.
    • Ce dont le service a besoin: En plus du point de départ et d’un point d’arrivée (respectivement coordonnées, adresse, POI ou arrêt) (comme pour TripRequest), il faut des points intermédiaires qui doivent être explicitement inclus ou exclus.
    • Ce que le service donne: La même chose que dans TripRequest et Le routing comprend aussi bien un routing des transports publics (en tenant compte des horaires actuels et des perturbations) qu’un routing du trafic individuel basé sur une carte (par ex. avec sa propre voiture) sur la base d’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 pour les itinéraires pédestres, une TurnDescription est généralement disponible (navigation décrite verbalement).
    • Pas de détails supplémentaires sur ce service pour l’instant.
  8. Ta situation : tu as fait calculer un itinéraire il y a quelques jours. Le jour du voyage est arrivé et tu souhaites consulter les dernières informations?
    • Ensuite, tu as besoin du (à partir de la version 2.0) TripRefinementRequest
    • Ce que fait le service: Mettre à jour un trajet déjà calculé. Il est important de noter que la demande n’est pas un nouveau calcul !
    • Ce dont le service a besoin: un trajet existant avec son contexte et ses paramètres. Les paramètres peuvent agir comme un filtre, par exemple en ne fournissant que les résultats partiels qui ne contiennent pas de niveaux.
    • Ce que le service donne: Le service actualise le voyage avec les compléments souhaités, s’il y en a. Important:
      • Il se peut que le service fournisse plusieurs trajets et pas (seulement) celui demandé.
      • Il peut arriver que le voyage précédent soit “cassé” lors de cette demande. Le voyage doit alors être recalculé.
      • Il faut donc toujours vérifier la réponse de TripRefinementRequest!
    • Pas de détails supplémentaires sur ce service pour l’instant.
  9. Ta situation: tu dois prolonger ton arrêt prévu à Olten? 
    • Ensuite, tu as besoin du (à partir de la version 2.0) TripChangeRequest
    • Ce que fait le service: Permet de prolonger le temps de séjour à un arrêt intermédiaire le long d’un trip et d’obtenir soit la section qui précède, soit celle qui suit. Les autres parties respectives pourraient donc être recalculées.
    • Ce dont le service a besoin: un leg existant ainsi que les adaptations souhaitées sur celui-ci.
    • Ce que le service donne: un voyage modifié selon les souhaits.
    • Pas de détails supplémentaires sur ce service pour l’instant.
  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. Plus de détails sur ce service en cliquant sur le lien suivant: OJP Sysrequest

Quels sont les principaux termes et concepts à connaître?

Pour 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 de bus. La taille d’un StopPlace peut varier. Les très grands arrêts, comme la gare de Berne ou la gare de Zurich, sont composés de plusieurs StopPlaces.
  • Journey, le “trajet”
    • Description: Un trajet est le transport de clients sur un itinéraire donné, une liaison horaire donnée, avec un moyen de transport donné, à une heure donnée, dans une direction donnée. Il existe différents types de parcours, par exemple: DatedJourney pour un trajet d’un moyen de transport à un jour donné.
  • Trip, le “voyage”
    • Description: Un “voyage” et donc une forme non spécifique de trajet plus concret. Un trip se compose de legs (voir ci-dessous).
  • Leg, la “section voyage”
    • Description: Une section d’un trip. Voici les différents types de Legs:
      • ContinuousLeg: un leg qui n’est pas lié à un horaire.
      • TimedLeg: un leg selon un horaire.
      • TransferLeg: un leg, pour un lieu où s’effectue un transfert.
  • 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, pour l’affichage d’une “station terminus/destination”. Il s’agit donc d’un “attribut artificiel” et la signification de la direction ne peut pas être déduite.
  • Facility
    • Description: Une facilité est un élément disponible à un “endroit” (par ex. un arrêt) ou sur un “service” (par ex. un véhicule). Les toilettes de la gare ou le wagon-restaurant en sont un exemple. Actuellement, ils sont repris des offres en HRDF (voir Informations sur le trafic). Le mapping s’effectue selon Notes2FacilitiesMappingFile.
  • Mode
    • Description: Les modes sont des moyens de transport possibles. Les modes autorisés sont:
      • ContinuousMode: mode qui ne dépend pas d’un horaire.
      • IndividualModes: transport individuel.
      • PtMode: PtMode est un mode dans les transports publics.
      • TransferModes: mode en rapport avec les transferts.
      • XXXRef: Ces éléments sont des 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.

Description technique

Accès à l’API

Pour pouvoir utiliser l’API/interface, il faut un jeton. Ce jeton peut être obtenu via le portail des développeurs.

Tous les services pour la version 1.0 sont disponibles via POST avec l’URL https://api.opentransportdata.swiss/ojp2020.

Tous les services pour la version 2.0 sont disponibles via POST avec l’URL https://api.opentransportdata.swiss/ojp20.

Vous pouvez essayer l’interface ici https://opentransportdata.swiss/fr/cookbook/open-journey-planner-ojp-api-explorer/ 

ou https://opentdatach.github.io/api-explorer2/  .

Fonctionnement de base de l’API

Requêtes simples

L’interface OJP correspond davantage à une interface SOAP XML classique qu’à une interface REST. Tous les accès se font via le point final mentionné.

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

La clé de travail actuelle est:

La distinction entre les services décrits ci-dessus se fait par le biais des requêtes correspondantes dans l’élément ServiceRequest. Dans cet exemple, nous exécutons une LocationInformationRequest.

Veillez à ce qu’ils fournissent une indication unique en tant que RequestorRef. Il s’agit ici d’identifier l’auteur de la demande. L’indication doit contenir le suffixe “_test”, “_int” ou “_prod”, afin que nous sachions depuis quel environnement l’accès a eu lieu lors d’analyses et de demandes d’assistance ultérieures.

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 classées dans l’ordre des requêtes, mais selon la séquence du XSD standard. C’est pourquoi il est extrêmement important, pour de telles demandes, que les MessageIdentifier soient définis par demande et puissent ensuite être lus dans la réponse. L’ordre par défaut est (version 1.0):

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

Restrictions et informations complémentaires

Restrictions

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

Informations supplémentaires