gart groupe de travail système dinformation multimodale 1/ web services itinéraires standardisés...

GARTGroupe de travail

Système d’Information Multimodale

1/ Web services itinéraires standardisés2/ Recherche distribuée d’itinéraires France

Laurent BRIANT - CitywayGuillaume CROUIGNEAU – Canal TP

le 29 janvier 2013

1

-1-API de recherche d'itinéraires transports collectifs

Version 0.9 – 15/02/2012

Etude & spécifications

Introduction

• Contexte– Besoin d’une API commune

• Etude : – Pas de standard de fait– API existantes pas satisfaisantes

• Conception :– Base Transmodel– Protocole standard

API de recherche d'itinéraires TC 3

Contextes d’utilisation

• Service de calcul d’itinéraires– API REST Xml/Json pour intégration complète et

personnalisé par un développeur.• « Marque blanche »

– Interface Html/Kml pour une intégration simple et rapide par un Web Master.

• Calcul réparti– Définition des bases techniques


Définition de l’API

• Deux méthodes :– “SearchPoints”– “PlanTrip”

• Plusieurs formats de sortie :– XML, JSON, HTML, KML

• Réponse basée sur un schéma XSD.


Service REST

• Simplicité d’utilisation• HTTP en GET ou POST• Clef d’accès


http://host/api/[api]/[version]/[méthode]/[format]?key=[clef utilisateur]&([param]=[valeur])*

SearchPoints


• Objectif :– Permettre d’identifier un point pour l’utiliser

comme origine ou destination dans la recherche d’itinéraires.

• Requête : – Un ou plusieurs mots clefs.

• Réponse :– Une liste de points typés et géocodés.

Requête PlanTrip


• Origine et destination par Id ou position géographique (WGS84)

• Mode de transport TC standard (Trident)• Options d’optimisation classiques : + rapide, -

de changement, + court.• Plusieurs solutions possibles• Support du multilingue

Réponse PlanTrip


• Modèle multi-solutions

• Un statut de réponse

• Des solutions « adresse - adresse »

Réseau TC, voirie, tous modes

Réponse PlanTrip


Choix de modélisation

Déplacement sous forme (départ, arrivée)

Horaires sans ambiguïté Distinction horaires départ et arrivée

Plusieurs niveaux de détail des solutions

Résumé et détails Plusieurs niveaux de tracé

Réponse PlanTrip


Informations de synthèse

Tracé global d'une solution

Réponse PlanTrip


Tracé d'une section sur voirie

Tracé d'un déplacement unitairesur voirie

Réponse PlanTrip


Souplesses pour la partie TC

Référence ou description des données TC Distinction arrêt commercial – physique Tout ou partie des arrêts

• Précision

Guidage pour la partie « in-door » Evaluation de l'attente

Réponse PlanTrip


• Évolutivité du modèle

Des structures d'extension L'accessibilité Le TAD Les perturbations L’intermodalité

HTML


• Objectif : favoriser l’intégration sur des sites tiers– Aucune connaissance métier ne doit être

nécessaire– L’intégration technique doit être facile

• Requête : – Même interface que l’API Rest, en précisant le

format HTML en sortie

HTML


• Réponse :– Un document HTML formaté par :

• Un résumé de l’itinéraire demandé• Un résumé de l’itinéraire calculé• Une carte OpenLayers affichant le tracé de l’itinéraire

sur la carte• Le détail de la feuille de route structuré sous forme de

liste à puces

– Présentation personnalisable par feuille de style

HTML


Exemple de réponse :

Cartographie


• Format KML• Simplicité d’utilisation• Personnalisation

-2-APII-SIM

Protocole standardisé pour une recherche d’itinéraire distribuée

-

Avec le soutien de l’Agence française pour l'information multimodale et la billettique (AFIMB)

Direction générale des Infrastructures, des Transports et de la Mer

Pourquoi ce projet ?

• Il n’existe pas en France de calculateur d’itinéraires réparti entre plusieurs SIM, alors que les besoins des usagers ne s’arrêtent pas aux frontières administratives.

• La seule solution d’interopérabilité actuelle est l’initiative privée EU-SPIRIT dont Canal TP et Cityway ont chacun constaté les limitations techniques et fonctionnelles.

Recherche d'itinéraires distribuée

Les objectifs

• Rendre possible le calcul d’un itinéraire de porte à porte, principalement TC, mais à vocation multimodale

• A cet effet, élaborer des spécifications d’interface publiques: une API RI distribuée

• Illustrer l’utilisation de cette API RI à l’aide d’un démonstrateur fonctionnant sur quelques SIM

• le démonstrateur est constitué de briques élémentaires, dont des modules Open Source publics

• Faciliter l’adoption par les SIM existants • Les SIM servent de point d’entrée à la requête de

l’usager.


Les principes

Une architecture technique dépassant l’état de l’art international :

- éviter le recours à une base partagée de points d’interconnexion, sans compromettre les performances

- offrir un résultat de qualité dans le cas de SIM adjacents


Comment ?

• Un partenariat privé Canal TP - Cityway pour étudier puis développer des standards de communication ouverts

• Soutien de l’AFIMB• Présentation des propositions au groupe de

normalisation et objectif de diffusion à tous les acteurs du marché


Le processus d’ensemble

• Etape antérieure: API standard RI – Disponibilité publique

• Le projet en phase de démarrage: APII - SIM– Illustration à partir de plusieurs SIM :

• 2 SIM contigus• 2 SIM distants

• La suite: toutes initiatives possibles à partir de l’APII -SIM


L’architecture généraleSIM régional 1

Interfaces exposées

Front Office

Back Office

Composeur d’itinéraires

Métadonnées

SIM régional 2


Serveur longue distance


Les métadonnées : un annuaire technique des SIM

Pour chaque SIM : • les paramètres d'accès au Web Service, • les paramètres d'interface supportés,• la couverture géographique du calculateur

d'itinéraire,• les modes supportés.


Les interfaces

• Élaborer les interfaces: – qui fournissent dynamiquement au composeur les

points d’interconnexion où il sera possible de passer du périmètre d'un calculateur SIM ( ou serveur) à celui d'un autre.

– qui fournissent au composeur la partie d’itinéraire calculée par un SIM.

Ce dernier interface s’appuiera sur les principes résultant de l’« API simple d’accès au calculateur d’itinéraires »


Le serveur longue distance

• Simulé pour les besoin du prototype• A terme tout serveur longue distance :

• Mappy• Voyages Sncf• Amadeus• Motricity• EU-SPIRIT• ….


Le composeur d’itinéraires• Identification des départ et arrivée, ainsi que des

paramètres de la demande, • En s'appuyant sur des paramètres et les

métadonnées, identification des calculateurs contribuant à l'élaboration des itinéraires correspondant à la demande,

• Sollicitation de ces calculateurs, en utilisant les spécifications d’interfaces

• Combinaison et agencement des résultats pour obtenir un ou plusieurs itinéraires

• Présentation de ces itinéraires


Le composeur d’itinéraires

Cas 1 : SIM distants

Territoire 1

Territoire 2Offre gérée par le serveur longue distance

Points d’interconnexion



Cas 2 : SIM adjacentsTerritoire 1 Territoire 2

Offre dupliquée





• Le composeur sera en Open Source• L’instanciation sera à déterminer en fonction

de la gouvernance définie par les AOT• Les réutilisateurs pourront l’adapter librement

à leurs besoins (voire localement).


Le planning• T0 = Janvier 2013• Phase de lancement – 2 mois

– Recherche préalable – Etat de l’art– Formalisation des besoins utilisateurs– Identification des contraintes techniques– Synthèse- Formalisation des exigences fonctionnelles– Présentation au GT7

• Analyse des conclusions – 1 mois• Phase de Conception – 3,5 mois

– Architecture générale du système - Architecture technique– Spécification technique des composants– Spécifications fonctionnelles– Présentation au GT7

• Analyse des conclusions – 1 mois• Phase de Réalisation – 6 mois

– Des communications intermédiaires de chaque composant seront effectuées.

• Phase de résultat – 1,5 mois

• Exploitation – 3 mois


Merci

Vos contacts :• Guillaume CROUIGNEAU – Canal TP

[email protected]

• Laurent BRIANT – [email protected]

mailto:[email protected]

mailto:[email protected]

gart groupe de travail système dinformation multimodale 1/ web services itinéraires standardisés...

Documents