Transcript 2.Presentation_RI_GART CW-CTP

GART
Groupe de travail
Système d’Information Multimodale
1/ Web services itinéraires standardisés
2/ Recherche distribuée d’itinéraires France
Laurent BRIANT - Cityway
Guillaume CROUIGNEAU – Canal TP
le 29 janvier 2013
1
Etude & spécifications
-1API de recherche d'itinéraires
transports collectifs
Version 0.9 – 15/02/2012
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
http://host/api/[api]/[version]/[méthode]/[format]?
key=[clef utilisateur]&([param]=[valeur])*
API de recherche d'itinéraires TC
6
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.
API de recherche d'itinéraires TC
7
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
API de recherche d'itinéraires TC
8
Réponse PlanTrip
•
Modèle multi-solutions
•
Un statut de réponse
•
Des solutions « adresse - adresse »

Réseau TC, voirie, tous modes
API de recherche d'itinéraires TC
9
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
 Plusieurs
détails
niveaux de tracé
API de recherche d'itinéraires TC
10
Réponse PlanTrip
Informations de synthèse
Tracé global d'une solution
API de recherche d'itinéraires TC
11
Réponse PlanTrip
Tracé d'un
déplacement unitaire
sur voirie
Tracé d'une section sur voirie
API de recherche d'itinéraires TC
12
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
API de recherche d'itinéraires TC
13
Réponse PlanTrip
•
Évolutivité du modèle

Des structures d'extension

L'accessibilité

Le TAD

Les perturbations

L’intermodalité
API de recherche d'itinéraires TC
14
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
API de recherche d'itinéraires TC
15
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
API de recherche d'itinéraires TC
16
HTML
Exemple de réponse :
API de recherche d'itinéraires TC
17
Cartographie
• Format KML
• Simplicité d’utilisation
• Personnalisation
API de recherche d'itinéraires TC
18
-2APII-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érale
SIM régional 1
SIM régional 2
Interfaces exposées
Interfaces exposées
Serveur longue distance
Interfaces exposées
Composeur
d’itinéraires
Métadonnées
Front Office
Back Office
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
Offre gérée par le
serveur longue distance
Territoire 2
Points
d’interconnexion
Territoire 1
Recherche d'itinéraires distribuée
Le composeur d’itinéraires
Cas 2 : SIM adjacents
Territoire 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
–
–
–
–
–
•
•
Analyse des conclusions – 1 mois
Phase de Conception – 3,5 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
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
Merci
Vos contacts :
• Guillaume CROUIGNEAU – Canal TP
[email protected]
• Laurent BRIANT – Cityway
[email protected]