Comment on page
28/08/2020 - Transports personnels, Autopartage #1
Participants
Nicolas Frasie (Communauto et Association des Acteurs de lâAutopartage), Gilles Kister (Citiz), Josée Sabourin (Mobility Data), Julien de Labaca (Mobility Data), Fabien Serra (MyBus), Vincent Szaleniec (Ãle-de-France Mobilités), Mélanie Gidel (Mairie de Paris), Patrick Pigache, (Mairie de Paris), Antoine Sarazin (Instant System), Loïc Ciprian (Instant System), Christophe Le Guern (Mobility by Colas), Martin Rueda, Miryad (transport.data.gouv.fr), Jeanne (transport.data.gouv.fr), Antoine (transport.data.gouv.fr), Nicolas (transport.data.gouv.fr),
Cet atelier a été coanimé avec lâAssociation des Acteurs de lâAutopartage (AAA) et MobilityData. Nous collaborons avec ces deux associations afin dâétablir une extension du format GBFS qui sera adapté aux données dâautopartage.
â
- 1.Obligations réglementaires pour les producteurs de données : transport.data.gouv.fr
Les données dâautopartage font partie des données de niveau 2 (modes à la demande et transports personnels). Lâéchéance dâouverture est fixée au 1er décembre 2020.
Les informations concernées sont les suivantes
- localisation
- disponibilité des véhicules
- modalités d'achat des billets
- caractéristiques des véhicules
2. Zoom sur le format GBFS : MobilityData
- Historique
Le format été créé par lâassociation américaine NABSA pour les données des vélos partagés. Ce format est utilisé par plus de 270 opérateurs dans le monde. NABSA a contractualisé avec MobilityData pour développer et enrichir le GBFS à l'échelle mondiale.
Le GBFS est un agrégat de fichiers, trÚs proche du GTFS. Il est toutefois plus restreint que le GTFS, avec moins d'extensions et de détails.
Historiquement, l'objectif du GBFS n'était pas de faire de la régulation mais de l'information voyageur en renseignant les informations suivantes :
* Localisation des stations ;
* Situation des stations (pleines ou vides) ;
* Disponibilités des vélos en temps-réel.
Ces données peuvent être réutilisées dans des applications servant à lâinformation voyageur comme Lime ou GoogleMaps
- DerniÚres évolutions
Le processus de gouvernance pour le GTFS est basé sur lâitération continuelle de ce format de données afin de lâadapter aux besoins des usagers. Ces améliorations du format de données sont faites en collaboration avec les opérateurs de transport et les réutilisateurs. Pour cela, un Github ouvert à tous a été créé avec des :
* issues : pour poser des questions, relever des problÚmes remarqués sur le schéma proposé etc. ;
Un processus de vote a également été mis en place avec 7 jours de vote afin de savoir si le schéma de données proposé est adopté ou non. 1 vote « non » met le vote en échec. La proposition est alors abandonnée ou revisitée.
La version 2.0 est la derniÚre en date. Les versions GBFS 2.1 et 3.0 sont à venir avec de nouvelles fonctionnalités.
- GBFS adapté à l'autopartage
Ce format est une bonne base pour l'autopartage :
* Il peut être utilisé sans station ou avec station
* Il donne des détails sur des stations et des véhicules individuels
* Il est intrinsÚquement itératif
* Il renseigne des données en temps réel
Présentation de la version alpha du schéma de données : lâextension GBFS autopartage : AAA
Nous nous sommes basés sur trois types dâautopartage afin dâétablir ce schéma de données (issue Github : https://github.com/NABSA/gbfs/pull/255) :
- LâAutopartage en boucle
Une disponibilité actuelle nâa que peu de sens car les réservations se font dans le futur. Les véhicules affichés seront disponible entre maintenant et dans 3h, indifféremment de leur disponibilité future.
- Autopartage en free-floating
Il existe des services dâautopartage en free-floating où les véhicules peuvent être emprunté ou déposé dans une ou plusieurs zones mais également dans des stations, qui offrent un nombre limité de places disponibles (exactement comme des stations de vélo en libre-service).
- Autopartage en trace direct (ou *one-way*)
Lâautopartage en trace directe (Autolib, Bluely, Bluecub) est une exception française. Les véhicules peuvent être uniquement déposés dans des stations. LâAAA sâinterroge sur la pertinence de modéliser ce type dâautopartage.
- Retour sur les champs modifiés, rajouter dans le schéma adapté à lâautopartage et propositions dâaméliorations
vehicule_types : Décrit les différents types de véhicule proposés par le service dâautopartage
- Car_type
Permet de préciser le type de véhicule (2 places, 4 places, âŠ). Les valeurs proposées doivent être précisées.
- Seating_capacity
- Share_type
Puisquâun même service dâautopartage peut inclure plusieurs types de service, il nous semble utile dâajouter ce champ. Toutefois, ces différents types ont généralement un logo et un nom différent pour un même opérateur dans une même ville (exemple Yea ! et Citiz pour Citiz), ce qui pose la question de remonter ce champ dans system_information et dédoubler le lot de fichiers. Nous sommes intéressés dâavoir lâavis des réutilisateurs sur ce point.
- Min_fuel_level
Si le véhicule est à essence, un niveau minimum de carburant peut être demandé à la fin du trajet. Cette information peut également être remontée au system_information.
- Propulsion_type
Complexifier un peu les valeurs pour la question de l'accÚs au centre-ville. Question ouverte sur la possibilité de spécifier la vignette Crit'Air qui permettrait de savoir si le véhicule peut être utilisé ou non dans certaines zones (ZFE ou pic de pollution...).
Débat entre les participants :
Crit'Air serait limitatif car ne concerne que la France : MobilityData est plutÎt contre l'introduction de cette information trop spécifique à la zone France.
Normes euro se cantonne à l'Union européenne mais est déjà plus inclusive comme norme que Crit'Air**. Possibilité dâindiquer cette donnée en se basant sur les émissions de CO2, en faisant des tranches ? L'émission de CO2 es intéressante comme critÚre de choix pour les utilisateurs. Cela supposerait toutefois que l'utilisateur reconstitue l'information aprÚs.
- user_age_condition :
Permet de renseigner certains véhicules qui sont accessibles avant 18 ans (ex. des quadricycle à moteur type Peugeot AMIOne)
- vehicule_desc
Donne des informations diverses propre à ce type de véhicule. Ce champ libre est libre et peut donc être personnalisé selon les usagers.
Débat entre les participants :
Il est demandé de prévoir une traduction en anglais. Nativement dans le GBFS, la langue des commentaires est unique pour un lot de fichiers, et indiqué dans le fichier gbfs.json.
- vehicule_accessories
Permet dâindiquer quels sont les accessoires qui sont (ou peuvent être) fournis avec le véhicule (pneus neige, siÚge bébé etc.). Ces accessoires doivent être visibles dans l'application de réservation.
- vehicle_image
Permet dâinsérer une ou plusieurs photos des véhicules.
- is_wheelchairaccessible
Permet de préciser si le véhiculeest accessible aux personnes en fauteuil roulant.
free_bike_status :
- vehicle_plate
Permet de saisir la plaque d'immatriculation
Débat ouvert : Ce champ permet de reconstituer les trajets du véhicule, et serait susceptible de poser un risque dâatteintes à la vie privée. Il est maintenu en option à ce stade.
- public_id :
Permet aux utilisateurs dâidentifier le véhicule.
Débat ouvert :
Il est préférable de renseigner la plaque d'immatriculation ou plutÎt le numéro d'identification public ?
Débat ouvert : Ce champ permet de reconstituer les trajets du véhicule, et serait susceptible de poser un risque dâatteintes à la vie privée. Il est maintenu en option à ce stade.
- current_range_% :
Permet dâindiquer non pas lâautonomie mais le pourcentage de remplissage de la batterie en pourcentage. Lâinformation « range » en km du véhicule nâest pas forcément disponible pour les opérateurs dâautopartage. Pour éviter de données une estimation qui ne soit pas cohérente avec celle affichée par le véhicule en début de trajet, les opérateurs préfÚrent parfois communiqués un % de charge de la batterie. Dans certains cas, les opérateurs préfÚrent ne pas indiquer lâautonomie.
Ce champ risque toutefois de devenir illisible pour lâutilisateur sâil y a différents modÚles.
station_information
- parking_hoop
Permet de signaler que la place est strictement réservée.
Le champ a finalement été intégré dans station_type.
- station_type
Type de station (en voirie, en sous-solâŠ).
- Share_type
Type dâautopartage que peut accueillir la station. En effet, il existe des services dâautopartage en free-floating où les véhicules peuvent être emprunté ou déposé dans une ou plusieurs zones mais également dans des stations, qui offrent un nombre limité de places disponibles (exactement comme des stations de vélo en libre-service).
- charging_capacity
Permet de préciser la présence de points de recharge pour véhicule électrique.
- step_free_access :
Permet dâindiquer si la station est accessible aux personnes à mobilité réduite.
- night_light
Permet de signaler si la station est éclairée la nuit ou non.
- station_desc
Pour les stations hors voiries (par exemple louées chez ZenPark),il y a besoin d'un champ libre textuel (potentiellement limité) pour indiquer à une personne que la place est au -6 entre la place 204 et 200 avec le digicode XXXX.
Débat
Potentiellement plusieurs champs pourraient être utilisés. Attention : on parle ici de données qui seront publiques ; ne pas indiquer le code dâun digicode par exemple. Attention aussi à l'internationalisation des champs libres.
Proposition : Ajout dâun champ pedestrian_access
- station_hours
Permet dâindiquer les horaires d'ouverture de la station. Habituellement, ouverture 24/7, mais il peut y avoir des exceptions.
Débat : Ce champ a été envisagé pour la location de voiture, avec lâintervention dâun agent. Il est proposé de supprimer ce champ.
Journée, heure de début, heure de fin
- Proposition : Ajout d'un champ de contact de la station
station_status
Modifications similaires à free_bike_status.
3. Retours des participants
- Le GBFS va être un modÚle de données assez complet : toutes ces données doivent-elles être remplies par tous les acteurs ?
Oui, certains champs seront obligatoires, d'autres optionnels. Les champs ne seront obligatoires que pour les données facilement mobilisables.
- Lien entre les véhicules et les stations ?
Pour certains systÚmes on peut appeler un service pour avoir la liste des stations dans lesquelles il y a un type dâautopartage. Inversement on peut demander la liste des véhicules qui sont présents dans une station.
- Quel temps de rafraîchissement de ces données sur le PAN ?
Le taux de rafraîchissement dépend du producteur car le PAN n'héberge par les données.
4. Publication des flux GBFS sur le PAN : transport.data.gouv.fr
- Référencement de l'URL sur fichier gbfs.json sur data.gouv par le producteur, puis l'équipe de transport.data.gouv.fr référence l'URL sur le PAN.
- Démonstration plus détaillée au prochain atelier
5. Etapes à venir
- Renvoi dâun lien Github vers le schéma avec les modifications intégrées pour que tout le monde puisse ajouter des commentaires, poser des questions etc. pendant un mois.
- Nouvel atelier dans un mois pour approuver ou non le schéma proposé
Objectif d'un schéma de données final pour le mois dâoctobre.
DerniÚre mise à jour 3yr ago