Upload
georgine-weiss
View
105
Download
1
Embed Size (px)
Citation preview
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
API de recherche d'itinéraires TC 4
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.
API de recherche d'itinéraires TC 5
Service REST
• Simplicité d’utilisation• HTTP en GET ou POST• Clef d’accès
API de recherche d'itinéraires TC 6
http://host/api/[api]/[version]/[méthode]/[format]?key=[clef utilisateur]&([param]=[valeur])*
SearchPoints
API de recherche d'itinéraires TC 7
• 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
API de recherche d'itinéraires TC 8
• 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
API de recherche d'itinéraires TC 9
• Modèle multi-solutions
• Un statut de réponse
• Des solutions « adresse - adresse »
Réseau TC, voirie, tous modes
Réponse PlanTrip
API de recherche d'itinéraires TC 10
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
API de recherche d'itinéraires TC 11
Informations de synthèse
Tracé global d'une solution
Réponse PlanTrip
API de recherche d'itinéraires TC 12
Tracé d'une section sur voirie
Tracé d'un déplacement unitairesur voirie
Réponse PlanTrip
API de recherche d'itinéraires TC 13
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
API de recherche d'itinéraires TC 14
• Évolutivité du modèle
Des structures d'extension L'accessibilité Le TAD Les perturbations L’intermodalité
HTML
API de recherche d'itinéraires TC 15
• 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
API de recherche d'itinéraires TC 16
• 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
API de recherche d'itinéraires TC 17
Exemple de réponse :
Cartographie
API de recherche d'itinéraires TC 18
• 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.
Recherche d'itinéraires distribuée
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
Recherche d'itinéraires distribuée
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é
Recherche d'itinéraires distribuée
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
Recherche d'itinéraires distribuée
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
Interfaces exposées
Serveur longue distance
Interfaces exposées
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.
Recherche d'itinéraires distribuée
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 »
Recherche d'itinéraires distribuée
Le serveur longue distance
• Simulé pour les besoin du prototype• A terme tout serveur longue distance :
• Mappy• Voyages Sncf• Amadeus• Motricity• EU-SPIRIT• ….
Recherche d'itinéraires distribuée
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
Recherche d'itinéraires distribuée
Le composeur d’itinéraires
Cas 1 : SIM distants
Territoire 1
Territoire 2Offre gérée par le serveur longue distance
Points d’interconnexion
Recherche d'itinéraires distribuée
Le composeur d’itinéraires
Cas 2 : SIM adjacentsTerritoire 1 Territoire 2
Offre dupliquée
Points d’interconnexion
Points d’interconnexion
Recherche d'itinéraires distribuée
Le composeur d’itinéraires
• 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).
Recherche d'itinéraires distribuée
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
Recherche d'itinéraires distribuée