#AutoTranslate
Description rapide
Cette(s) page(s) contient(s) des descriptions de la manière de résoudre des «problèmes» spécifiques avec OJP (v.1 ou v.2).
À l’origine, l’OJP est un protocole entre les planificateurs de voyage. C’est pourquoi on suppose généralement qu’il existe un deuxième composant entre le service OJP suisse et le frontend/l’application. Cela signifie que la logique commerciale peut résider dans les éléments suivants:
- Le service OJP (OJP)
- Le back-end de l’application (BE)
- L’appli (appli)
Si vous avez besoin d’autres cas d’utilisation, veuillez nous envoyer un e-mail à opendata@sbb.ch afin que nous puissions mettre à jour cette page. Nous serions également heureux de recevoir vos commentaires lorsque nous avons besoin de mettre à jour ou de détailler certaines sections.
Description métier
Nous décrivons ci-après différents cas d’usage et problématiques pour lesquels nous proposons des conseils et astuces élargis.
Traitement des informations relatives à l’accessibilité
L’OJP calcule les informations sur l’accessibilité pour tous les trajets. Celles-ci se composent, d’une part, des informations sur l’accessibilité de l’arrêt issues des données de base d’Atlas et, d’autre part, de l’attribut «plancher surbaissé» des véhicules ou, pour les trains, des attributs correspondants disponibles pour chaque voiture ou wagon à partir des données de formation.
Cela permet de déterminer le taux d’autonomie correspondant pour le conducteur d’un fauteuil roulant, qui est affiché dans le paramètre «NameSuffix» dans la zone «LegBoard» ou «LegAlight» de la TripResponse. Dans le meilleur des cas, la mention «PLATFORM_ACCESS_WITHOUT_ASSISTANCE» y est indiquée, ce qui permet aux personnes en fauteuil roulant d’embarquer sans autre.
Plus d’informations à ce sujet dans la description des TripResponse.
Installer des formations
Actuellement, l’OJP ne contient pas de données de composition, celles-ci se trouvent dans l’API de formation décrite ici: Train Formation Service (composition de train)
Nous disposons d’un exemple d’implémentation pour la visualisation de la chaîne courte. Celle-ci peut être utilisée ainsi et se trouve chez nous sur GitHub: Visualisation de la formation Swiss Train
Dans sa propre Application de démonstration OJP si cette visualisation est ouverte avec l’API Formation, un lien est créé à partir de la page GitHub, du numéro de train et du numéro d’exploitant. Ces informations se trouvent dans l’élément «DatedTrainNumberRefGroup» sous le jour du service dans les messages OJP suivants: «TripResponse», «TripInfoRespons», «StopEventResponse» et «TripRefineResponse».
La visualisation de la chaîne courte est open source et peut être utilisée pour n’importe quelle application. Des solutions individuelles peuvent être réalisées en intégrant des données supplémentaires et plus détaillées mises à disposition via l’API de formation.
Intégrer le bouton «Fare»
OJPFare permet d’accéder à l’information sur les prix NOVA (cf. Bêta: Informations sur les prix OJPFare pour les transports publics suisses – Jeu de données – opentransportdata.swiss – CKAN data catalog). Il convient de noter qu’OJPFare fonctionne actuellement uniquement pour OJP 1,0.
Veuillez noter que, dans de rares cas, il n’y a pas de 1re classe et que le billet restitué dans NOVA peut être une carte journalière de 1re classe à prix réduit.
Que faire si j’ai besoin du prix d’un billet aller-retour dans OJPFare?
Les renseignements sur les prix ne sont pas destinés à cela. Il convient d’utiliser la procédure suivante pour le calcul:
- Recherche de A à B
- Recherche de B–A (départ après l’arrivée à B, avec suffisamment de tampon)
- Enchaînement des résultats
- Alimentation du trajet plus long résultant dans OJPFare
C’est nécessaire, car avec LIBERO par exemple, un billet aller-retour peut être une carte journalière et est donc moins cher.
Il doit être clair qu’Alliance SwissPass restreint délibérément le renseignement sur les prix.
Enregistrement de voyages
Le service OJP est sans état. Les voyages recherchés doivent donc être gérés dans l’appli car cela évite d’échanger des préférences personnelles via les services et garantit ainsi au mieux la protection des données personnelles. Avec OJP 2,0, OJPTripRefineRequest ce que l’implémentation par rapport au OJPTripInfromationRequest encore simplifié.
Si les préférences de recherche générales doivent être évaluées, il convient de se faire par l’intermédiaire de l’unité d’affaires de l’appli.
Mettre à jour les informations relatives à un voyage
- La TripInfoRequest actualise les informations sur les JOURNEYs (c.-à-d. Single Leg). la JourneyRef peut être utilisée à cet effet. Le back-end doit alors mettre à jour le voyage. Il doit également remarquer quand le voyage est interrompu (p. ex. le JOURNEY n’existe plus ou est trop retardé).
- La TripRefinementRequest permet de mettre à jour un trajet défini à partir du service OJP. Toutefois, le résultat ne peut plus être viable. Cela doit être vérifié par le back-end.
- Si le trajet est interrompu et qu’une nouvelle recherche partielle ou complète est nécessaire (selon qu’il a déjà commencé ou non).
Via multiple
Notre implémentation d’OJP ne prend en charge qu’un seul VIA. Si plusieurs VIA sont nécessaires, le backend doit rechercher les différentes parties de manière séquentielle. Exemple:
- Recherche 1: A – Via B – C
- Recherche 2: C–via D–E
Les heures de début et de fin doivent être utilisées correctement et les trajets qui en résultent doivent être enchaînés avec des correspondances pertinentes.