• Aucun résultat trouvé

Accès dynamique aux données temps réel via les API Test temps réel

N/A
N/A
Protected

Academic year: 2022

Partager "Accès dynamique aux données temps réel via les API Test temps réel"

Copied!
42
0
0

Texte intégral

(1)

-

Accès dynamique aux données temps réel via les API Test temps réel

[Plateforme OpenData]

(2)

2

Ile-de-France Mobilités

Dans le cadre de ses missions d’information, Ile-de-France Mobilités collecte auprès des 75 opérateurs de transport d’Ile-de-France (RATP, SNCF et entreprises OPTILE), les données décrivant l’offre prévue de transport collectif (lignes, parcours, arrêts, horaires, calendrier, etc.).

A l’échelle de la Région, ces données sont considérables : c’est plus de 1 500 lignes de transport, près de 40 000 arrêts et environ 140 000 à 150 000 circulations par jour !

Ces informations alimentent les services d’information d’Ile-de-France Mobilités (Vianavigo), ceux des transporteurs et les services partenaires.

(3)

1. La démarche Open Data D’Ile-de-France Mobilités 2. Comment accéder aux API?

3. Les données

4. Description des données transport 5. Identification des objets

6. Annexes

1. Les points d’entrée de l’API

2. Exemples de requêtes / réponses 3. Liste des modifications apportées

Plan

(4)

4

La démarche Open Data d’Ile-de-France Mobilités

1

(5)

Concernant l’ouverture des données, Ile-de-France Mobilités a entrepris l’ouverture de données statiques et dynamiques via :

Le portail opendata.stif.info : données brutes et API

(exploration du réseau, horaires de passages théoriques, recherche d’itinéraire…)

Le portail API Test Temps Réel : services sur les prochains horaires de passages et l’info trafic en temps réel

Ile-de-France Mobilités et l’Open Data

(6)

6

Les API Test Temps Réel

Message info trafic (*)

Ce service transmet l’ensemble des perturbations qui surviennent sur le réseau en temps réel (travaux prévus et imprévus, incidents, pannes…).

Prochains passages à un arrêt (« requête unitaire ») Deux canaux fournissent les prochains horaires de passages calculés sur l’ensemble des arrêts du réseau d’Ile-de-France.

Actuellement deux canaux de données différents existent en fonction de la source des données (Vianavigo et la plateforme d’échanges d’Ile-de- France Mobilités ).

Prochains passages pour tous les arrêts (« requête globale ») (*)

Ce service permet d’obtenir sur tout le réseau, les horaires de passages pour toutes les lignes en un seul échange.

(*)

Actuellement, ces services sont disponibles pour une partie seulement du réseau qui tendra à croître progressivement.

(7)

Les API sont accessibles depuis deux espaces différents en fonction de la nature des requêtes et du quota autorisé par API.

Espace « requêtes unitaires »

(api-lab-trone-stif.opendata.stif.info)

Il regroupe les services suivants :

• Horaires de prochains passages à un arrêt (plateforme Ile-de-France Mobilités et Vianavigo)

• Info trafic à un arrêt ou pour une ligne

Espace « requête globale » (api-lab-trall-stif.opendata.stif.info)

Il met à disposition le service des horaires de prochains passages sur l’ensemble des arrêts du réseau en une seule requête/réponse.

2 espaces de tests sur la plateforme Open data

Temps réel

(8)

8

Comment accéder aux API ?

2

(9)

9

Accès aux API

Principes

Durant la phase d’expérimentation, les accès aux API Test Temps Réel sont limités à un quota de :

(*) 100 000 requêtes / jour pour les API proposant les horaires de prochains passages et l’info trafic pour un arrêt ou une ligne (espace unitaire);

(*) 300 requêtes/ jour pour l’APIproposant la requête globale.

Leur utilisation est soumise à l’acceptation de l’Opendata Base License (OdBL).

Authentification

Pour accéder à l’ensemble des API vous devez disposer d’un compte utilisateur et être inscrit sur chacun des espaces. La création du ou des comptes se fait directement depuis le site de l’APIvia l’onglet « Inscription ».

Attention : l’inscription à l’un de ces espaces est indépendante de l’autre, les deux étant elles-mêmes indépendantes del’inscriptionà l’APIOpen Data Ile-de-France Mobilités.

(10)

10

Accès aux API

Accès depuis des applications tierces

Pour chaque API, vous avez la possibilité d'ouvrir votre accès à des applications tierces.

Vous devez pour cela utiliser des clés d'API. Une clé d’API est obtenue via le portail de votre compte utilisateur dans la rubrique « Mes clés d’API »

Une fois générée, la clé est à insérer en paramètre de requête dans l’URL de votre appel. Le nom du paramètre est « apikey ».

Exemple d’appel depuis une application tierce : /general-message?apikey={votre clé d’API}

(11)

Les données

3

(12)

12

D’où proviennent les données?

L’ensemble des données temps réel provient des transporteurs. Ces données sont acheminées via deux canaux :

• La plateforme d’échanges Ile-de-France Mobilités

• Le service Vianavigo

Les systèmes d’aide à l’exploitation et à l’information voyageur (SAEIV) fournissent les données en temps réel. Les réseaux de transport des différents opérateurs ne sont pas tous équipés de SAEIV. La donnée sera donc entièrement disponible progressivement.

Réutilisateurs Vianavigo

Plateforme d’échanges Ile-de-

France Mobilités

(13)

D’où proviennent les données?

La plateforme d’échanges Ile-de-France Mobilités

1. Pour les réseaux équipés, la plateforme d’échanges Ile- de-France Mobilités va progressivement interroger tous les SAEIV. A terme, les horaires et informations de perturbations seront disponibles pour tous les arrêts et lignes des réseaux équipés.

Transporteurs Groupe

2

.

La plateforme récolte les informations et:

les diffuse aux autres transporteurs

les met à disposition de tout le monde (Opendata)

SAEIV SAEIV

SAEIV

Transporteurs indépendants

Réutilisateurs Plateforme

d’échanges Ile- de-France

Mobilités Concentrateurs

(14)

14

D’où proviennent les données?

Au travers du Canal Vianavigo, des données sur les horaires de passages à l’ensemble des arrêts de SNCF , RATP et Transdev sont disponibles.

SAEIV Vianavigo Réutilisateurs

Le service Vianavigo

Le canal Vianavigo est utilisé en complément, le périmètre des données n’étant pas encore totalement complet via la plateforme d'échanges d’Ile-de-France Mobilités.

SAEIV

SAEIV

(15)

Pour connaitre le périmètre (arrêts / lignes) des données disponibles via la plateforme d’échanges d’Ile-de-France Mobilités suivez ce lien.

La liste des données disponibles sera mise à jour toutes les 2 semaines.

Vianavigo permet d’obtenir les temps d’attente des prochains passages à l’ensemble des arrêts (métro, ferré, bus…) des transporteurs suivants : SNCF Transilien, RATP (bus, tram, métro, RER) et Transdev (réseaux TRA, CSO, Apolo 7, Montesson, Rambouillet, Vulaines, Lieusaint et Vaux le Pénil).

A terme, les données disponibles via Vianavigo vont disparaitre. Toutes les données temps réel seront disponibles via la plateformed’échanges d’Ile-de-France Mobilités.

Quelles données disponibles?

La Plateforme d’échanges Ile-de-France Mobilités

Le service Vianavigo

(16)

16

Format des données

Canaux de données

Services Format des

données

Pérennité

Plateforme d’échange Ile-de-

France Mobilités

Prochains passages pour tous les lignes disponibles

Prochains passages à un arrêt Info trafic/ perturbation

SIRI Lite Permanente

Service Vianavigo Prochains passages à un arrêt Json

« simplifié » Provisoire

Selon le canal de distribution des données, ces dernières ne sont pas au

même format pour des raisons techniques.

(17)

Qualité des données

Prochains horaires : définition

Pour tous les modes, les données sont disponibles sur une profondeur de deux heures.

Tant que le véhicule n’a pas commencé sa course, le système fournit les horaires de passages planifiés par l’exploitant la veille de la journée en cours.

Pour les courses en circulation :

• Bus : prévision de passage à un arrêt en fonction de la localisation du bus en prenant compte des circulations précédentes.

• Mode ferré : prévision de passage à un arrêt en fonction de la localisation

du véhicule.

(18)

18

Qualité des données

Info trafic : périmètre

• RATP : ensemble des infos trafics disponibles en gares RER et stations de métro et sur les médias RATP

• SNCF : informations disponibles sur les écrans disposés dans les gares

• Bus : informations disponibles sur les écrans disposés aux arrêts de bus

Ce qui signifie que pour la SNCF et le réseau de Bus OPTILE, les API Test Temps Réel ne dispose pas des informations qui sont fournies sur les médias (site internet, twitter,…).

(19)

Description des données transport

4

(20)

20

Qu’est-ce qu’une ligne de transport?

Une ligne regroupe un ou plusieurs itinéraires prédéfinis de

transport en commun définissant un service offert au public bien identifié, le plus souvent par un nom ou un code commercial (voyageur).

Exemple : la ligne de bus 250, le tramway T5, le RER A, etc.

(21)

Qu’est-ce qu’une ligne de transport?

Nom Définition Appellation

Canal Vianavigo

Appellation Canal Plateforme d’échanges Ile-de- France Mobilités

Ligne Une ligne est un ensemble d’itinéraires regroupés

sous un même nom. Line Line

Itinéraire

Un itinéraire définit un enchaînement structuré d’arrêts.

Une ligne simple est généralement composée de 2 itinéraires : un décrivant le sens aller, l’autre

décrivant le sens retour.

route route

Course

Une course est la déclinaison d’un itinéraire à un horaire donné. Une course attribut à chaque arrêt

de l’itinéraire un horaire de passage.

Sur une journée, une course est unique : deux véhicules d’une même ligne effectuent chacun une

course différente.

vehicle_journey Monitored VehicleJourney

(22)

22

Qu’est-ce qu’un arrêt?

Sur le terrain, un arrêt peut prendre de multiples formes : un zébra sur la voirie, une gare routière, une station de métro, une gare, un pôle d’échanges…

Il constitue à la fois le lieu où s’arrête les véhicules mais aussi des pôles multi modaux importants : un arrêt de transport en commun est un objet complexe à modéliser !

(23)

Dans le référentiel d’arrêts Ile-de-France Mobilités, on distingue quatre niveaux d’arrêts :

Qu’est-ce qu’un arrêt?

Appellation du référentiel

Définition Données GTFS / API

Zone d’embarquement (ZDE)

Endroit où le voyageur attend, montre

ou descend du véhicule StopPoint (Arrêt physique)

Zone de Lieu (ZDL)

Regroupement , au sein d’un lieu d’arrêt, de zones d’embarquement portant le

même nom commercial

StopArea (arrêt commercial)

Lieu d’Arrêt (LDA) Regroupement d’arrêts physiques de

plusieurs transporteurs StopPlace

Groupe de Lieux (GDL) Pour les lieux complexes à visibilité internationale

(24)

24

Les horaires

Les horaires fournis dans les services StopMonitoring, GeneralMessage et EstimatedTimeTable sont représentés selon la norme internationale ISO 8601 et sont exprimés en heure UTC (Temps universel Coordonné).

En ce qui concerne les données issues du canal Vianavigo, les horaires de passages à l’arrêt sont fournisen temps d’attenteexprimés en minutes.

Les perturbations

Chaque perturbation est localisée sur des lignes ou des arrêts avec des identifiants issus des référentiels.

Pour les messages de perturbations, trois types de textes peuvent être fournis:

Un texte brut (textOnly) qui est obligatoire et qui sera toujours renseigné.

Deux autres textes facultatifs qui ne seront pas forcément renseignés :

Un message court (shortMessage)

Un message long qui peut posséder des éléments de mise en forme (longMessage)

Les données diffusées

(25)

Restrictions sur les données et leur interrogation

• Prévision d’horaires de prochains passages : la précision est approximative au-delà de 20 minutes pour le bus et 30 minutes pour les modes ferrés ;

• Les quotas d’appels sont à la journée ; il est fortement recommandé de lisser le nombre de requêtes dans le temps afin de ne pas perturber le fonctionnement pour les autres utilisateurs ;

• Il est recommandé d’activer dans les headers de vos requêtes l’élément

« Accept-encoding : gzip, deflate » afin de diminuer la bande passante ;

• Compte tenu de sa taille très importante, la réponse à une requête globale sera transmise en mode « chuncked » (transmis par blocs successifs et géré par le protocole HTTP 1.1).

Précautions d’usage

(26)

26

Horaires théoriques et estimés

Champs facultatifs

DirectionRef : Il n’y a pas de référentiel partagé à l’échelle d’Ile-de-France Mobilités, le champ est donc facultatif.

Cependant le champ DestinationRef, le terminus de la course, est systématiquement renseigné.

Précautions d’usage

Nom Description

Format d’échange

Horaires théoriques fournis par les transporteurs 3 semaines à

l’avance GTFS

AimedArrival /DepartureTi

me

Horaires théoriques de départ et d’arrivée établis la veille par le transporteur en prenant en compte la disponibilité des conducteurs

et des véhicules. (pas toujours disponible)

SIRI

ExpectedArri val/Departur

eTime

Prédictions d’horaires de prochains passages prenant en compte la position réelle du véhicule, le temps restant pour atteindre un arrêt

et les temps de parcours observés sur les circulations précédentes

SIRI

(27)

Identification des objets

5

(28)

28

Les principes selon le canald’appel

• Selon le canal utilisé les données ne sont pas identifiées de la même manière.

• Les données issues de la plateforme d’échanges Ile-de-France Mobilités dépendent des référentiels des arrêts et des lignes.

• Celles issues du canal Vianavigo ont les mêmes identifiants que ceux du GTFS (ou API Ile-de-France Mobilités).

Pour les arrêts, la relation (de type 1..n) entre identifiants du référentiel et GTFS se trouve dans l’un des fichier du GTFS : stop_extensions.txt.

Pour les lignes, la relation entre identifiants du référentiel et GTFS se trouve dans le jeu de données « Référentiel des lignes de transport en commun d'Ile-de-France », il s’agit respectivement des champs ID_Line et ExternalCode_Line.

Identification des objets

(29)

Identifications des courses

• L’identifiant de la course DatedVehicleJourneyRef identifie de manière unique une course pour tous les transporteurs, la course est donc reconstituée dans une réponse à une requête globale.

Attention : La RATP ne fournit pas d’identifiants de courses mais un compteur technique sans lien métier avec la notion de course. Nous obtenons alors dans la réponse à la requête globale pour une même ligne et un même sens tous les véhicules s’arrêtant à la même heure quel que soit l’arrêt. Par conséquent, dans les réponses aux requêtes globales, les courses RATP ne sont pas correctement reconstituées. Les prochains passages aux arrêts sont cependant tous renseignés dans la réponse.

Identification des objets

(30)

30

Identifications des arrêts

• Les identifiants des arrêts présents dans le GTFS sont des identifiants propres à chaque transporteur. En conséquence, un arrêt de bus unique (même poteau ou même abri) par exemple partagé par 2 transporteurs aura 2 identifiants. Par ailleurs, ces identifiants ne sont pas pérennes dans le temps. Entre 2 générations du fichier GTFS, les identifiants d'un même arrêt pour un même transporteur peuvent changer.

• Le référentiel des arrêts Reflex au niveau ZDE identifie de manière unique et pérenne un arrêt, même s'il est partagé par plusieurs transporteurs.

Il y a donc une relation 1..n entre identifiants Reflex ZDE et identifiants GTFS. Le fichier stop_extension.txt du GTFS permet de faire la relation. Il est mis à jour à chaque génération du fichier GTFS.

Identification des objets

(31)

Données issues de la plateforme d’échanges Ile-de-France Mobilités

Identifiant de la ligne est « LigneRef » : STIF:Line::CXXXXX:

Avec XXXXX le code commercial de la ligne.

Exemples :

• Pour la ligne B du RER, l’identifiant commercial de la ligne est C01743, le pattern est donc

« STIF:Line::C01743: »

• Pour la ligne de bus Phébus A, l’identifiant commercial de la ligne est C00692, le pattern est donc « STIF:Line::C00692: »

Construction de l’identifiant de la ligne

(32)

32

Données issues du service Vianavigo

L’identifiant de la ligne (paramètre « Line_id ») est le même que celui du GTFS (route_id).

Exemples :

• Pour la ligne C du RER, l’identifiant GTFS (route_id) de la ligne est le « 810:C »

• Pour la ligne 12 du métro, l’identifiant GTFS (route_id) de la ligne est le « 100110012:12 »

• Pour la ligne de bus Transdev Mélibus C, l’identifiant GTFS (route_id) de la ligne est le

« 066066022:C »

Pour plus de détails sur les identifiants GTFS voir la documentation GTFS.

Il est aussi possible de passer en paramètre l’identifiant utilisé par les API Ile-de-France Mobilités (external_code).

Construction de l’identifiant de la ligne

(33)

Données issues de la plateforme Ile-de-France Mobilités

Identifiants des arrêts physiques de bus : STIF:StopPoint:Q:XXXXXX:

Avec XXXXXX, l’identifiant de la zone d’embarquement (ZDE)

Identifiants des arrêts commerciaux de bus : STIF:StopArea:SP:XXXXXX:

Avec XXXXXX, l’identifiant de la zone de Lieu (ZDL)

Exemples « Gare de Massy-Palaiseau »

•Pour la granularité ZDE et l’arrêt sur la ligne B du RER, l’identifiant du référentiel est 412833, le pattern est « STIF:StopPoint:Q:412833: »

•Pour la granularité ZDL, l’identifiant du référentiel est commun pour les lignes B et C et est 58774, le pattern est « STIF:StopArea:SP:58774: »

• Pour la granularité LDA qui comprend les gares routières environnantes, l’identifiant est 63244, le pattern est « STIF:StopArea:SP:63244: »

Construction de l’identifiant du point d’arrêt

(34)

34

Données issues du service Vianavigo

L’identifiant d’un point d’un arrêt (paramètre « stop_point_id » ) est le même que celui du GTFS (stop_id).

Exemples :

Pour l’arrêt Gare des Invalides de la ligne RER C, l’identifiant de l’arrêt physique est le

« stopPoint:8739303:800:C » même que celui du GTFS

des Invalides

Pour l’arrêt Gare des Invalides de la ligne RER C, l’identifiant de l’arrêt physique est le

« stopPoint:8739303:800:C »

Pour l’arrêt Gare de Melun de la ligne de bus Transdev Mélibus C, l’identifiant de l’arrêt physique est le « stopPoint:27:135 »

Pour plus de détails voir la documentation GTFS.

Il est aussi possible de passer en paramètre l’identifiant utilisé par les API Ile-de-France Mobilités (external_code).

Construction de l’identifiant du point d’arrêt

(35)

Annexes

6

(36)

36

Les points d’entrée de l’API

Prochains passages à un arrêt

GET/ stop-monitoring Prochains horaires de passages à un arrêt (plateforme d’échanges)

GET/ departures Prochains horaires de passages à un arrêt (service Vianavigo) Prochains passages aux arrêts (tout le réseau)

GET/ estimated-timetable Prochains horaires de passages de l’ensemble des arrêts du réseau

Info trafic

GET/ general-message Messages d’info trafic par ligne ou par arrêt

Qu’est-ce qu’un point d’entrée ?

Un point d’entrée identifie l’emplacement d’une fonction particulière au sein de l’API. Les points d’entrée sont implémentés afin de simplifier l'utilisation de l'API en répondant aux principaux cas d'usages.

(37)

Canal plateforme d’échanges Ile-de-France Mobilités

StopMonitoring : https://api-lab-trone-stif.opendata.stif.info/service/tr-unitaire- stif/stop-monitoring?MonitoringRef=STIF:StopPoint:Q:412833:

GeneralMessage sur l’arrêt : https://api-lab-trone- stif.opendata.stif.info/service/messages-it-stif/general- message?StopPointRef=STIF:StopPoint:Q:412833:

GeneralMessage sur la ligne : https://api-lab-trone- stif.opendata.stif.info/service/messages-it-stif/general- message?LineRef=STIF:Line::C01743:

Canal Vianavigo

Departuresur la ligne et l’arrêt : https://api-lab-trone- stif.opendata.stif.info/service/tr-

vianavigo/departures?line_id=810:B&stop_point_id=8775879:810:B

Exemple de requêtes

(38)

38

Exemples de réponses

Horaires de

prochains passages en temps réel

Canal plateforme d’échanges Ile-de-France Mobilités

(39)

Exemples de réponses

Messages Info Trafic

Canal plateforme d’échanges Ile-de-France Mobilités

(40)

40

Exemples de réponses

Temps

d’attente des prochains passages en

temps réel

Canal Vianavigo

(41)

Liste des modifications apportées (03/07/17)

Id Description

1 Ajout de la balise version pour l’ensemble des services (StopMonitoring, GeneralMessage et EstimatedTimetable) → conformément au profil SIRI Lite

2 Respect de la casse JSON, passage en lettre capitale des 1ères lettres de chaque champ pour l’ensemble des services (StopMonitoring, GeneralMessage et EstimatedTimetable) →conformément au profil SIRI Lite

3

Ajout de structures intermédiaires dans le delivery du service EstimatedTimetable {

"Siri": {

« ServiceDelivery": {

« EstimatedTimetableDelivery": [ {

«EstimatedJourneyVersionFrame": [ {

«EstimatedVehicleJourney": [ {

« DatedVehicleJourneyRef": {

"value": "RATP:VehicleJourney::M11.A.0637.1:LOC"

}

... →conformément au profil SIRI Lite

4 Ajout de la balise « ResponseTimestamp » dans les structures xxxDeliveryde l’ensemble des services (StopMonitoring, GeneralMessage et EstimatedTimetable) →conformément au profil SIRI Lite

5 Ajout de la balise « ResponseMessageIdentifier» pour l’ensemble des services (StopMonitoring, GeneralMessage et EstimatedTimetable) →conformément au profil SIRI Lite

6 La cardinalité des structures xxxDelivery passe de 1:1 à 1:n →conformément au profil SIRI Lite

7 Fiabilisation de la mise à disposition des données (certains arrêts pouvaient ponctuellement ne plus être alimentés dans la journée)

(42)

42

• Documentation SIRI Lite :

http://www.normes-donnees-tc.org/wp-content/uploads/2018/10/Proposition-Profil-SIRI- Lite-initial-v1-3.pdf

• Documentation API Departures :

https://api-lab-trone-stif.opendata.stif.info/api/datasets/1.0/tr- vianavigo/attachments/opendata_doc_apidepartures_v1_pdf/

• Documentation technique Navitia (API Ile-de-France Mobilités) :

http://doc.navitia.io/

Liens utiles

Références

Documents relatifs

– En utilisant notre système de localisation, le scan ne peut pas être réalisé en même temps que l’acquisition des électrodes.. A la place, la méthode développée ici utilise

Les systèmes à base de capteurs sont de plus en plus fréquemment utilisés pour de nombreuses applications comme la gestion de flottes de véhicules, la surveillance de trafic ou

● Utilisation de 2 sondes linéaires complémentaires d'une séquence cible - Une sonde marquée en 3' par un marqueur fluorescent, qui émet une fluorescence verte. - Une sonde

I.-Dans les conditions prévues au chapitre Ier du titre II du présent livre, peuvent être autorisées les interceptions de correspondances émises par la voie des

Comme c’est plus facile, et que c’est pratique, nous allons créer quelques règles à la volée.. J’ai crée un watch sur le fichier /etc/passwd, qui relèvera toute tentative en

Capture intrusive des données modifiées issues de vos systèmes sources transactionnels. Requêtes SQL ou triggers de base de données gourmands en

Nombre d'agents dans cette file d'attente de précision qui sont à l'état Non prêt, un état où les agents sont connectés mais n'effectuent aucune activité de traitement d'appel et

2 il apparaît clairement que les points sont bien représentés dans un espace à trois dimensions (96,5% de l'inertie) et que ceux relatifs aux engrenages acceptables se groupent