| Alpha Prototype — Feedback Welcome! |
Description sommaire
Les Service Directorys de services de mobilité sont des répertoires de services (API) qui aident à la planification et à la réservation de voyages. De tels annuaires jouent un rôle clé dans les scénarios de mise en réseau internationale de la mobilité, pour la MaaS (Mobility as a Service) et pour les assistants basés sur l’IA. Cependant, les normes et les protocoles ne sont pas encore bien établis.
Avec cette contribution, nous souhaitons contribuer au développement et à la standardisation de ce domaine.
Description spécifique
Qu’est-ce qu’un annuaire de services de mobilité?
Un service directory de services de mobilité est un répertoire électronique, lisible par une machine (également “catalog”, “registry”, “yellow pages”) de services (principalement des API) dans le domaine de la mobilité. Il soutient la recherche de fournisseurs (intermédiaires, courtiers) avec leurs interfaces de planification et de distribution (API). C’est donc une clé pour la planification de voyages intermodaux en plusieurs parties, y compris la tarification et la réservation qui s’ensuit (réservation, achat, paiement, clearing).
Pourquoi de telles directions de services sont-elles nécessaires ?
Actuellement, nous voyons ces arguments:
- Réglementation européenne: le règlement MMTIS de l’UE exige des PAN qu’ils fournissent certains ensembles de données. L’annexe définit environ 73 catégories de données. Certaines d’entre elles pourraient être construites sous la forme d’un répertoire. Les dispositions d’exécution précises sont actuellement (printemps 2024) élaborées dans le cadre d’un WG 3 de NAPCORE (avec la participation de notre équipe SKI+).
- Vision MaaS (Mobility as a Service): pour mettre en place un système MaaS international, interopérable et compatible avec l’itinérance, il faut des annuaires de services. Ce n’est que grâce à un annuaire qu’un client itinérant (par exemple un utilisateur MaaS de l’étranger pourrait trouver les services disponibles).
- Assistants/agents personnels basés sur l’IA: selon les prévisions de Gartner et d’autres fournisseurs d’analyses de marché IT, de nombreux achats seront effectués dans quelques années par des assistants ou agents basés sur l’IA. Les gens demandent alors à leur prompteur AI, par exemple, “comment puis-je voyager de A à B ?” et “réserve-moi ce voyage ! Pour cela, il faudra disposer d’annuaires structurés de fournisseurs de mobilité.
État actuel de la mise en œuvre
D’après nos observations, ce type de projet n’en est qu’à ses débuts. Dans de nombreux pays, aucun répertoire de ce type n’est connu en tant que données ouvertes. De même, la standardisation des formats de données et des processus pour ce faire fait défaut. Nous n’avons pas connaissance de normes au niveau européen (CEN) ou mondial (ISO) à ce sujet.
Il convient de mentionner l’exemple de la Finlande (PAN de la Finlande, https://finap.fi/#/services) avec un répertoire de 3000+ services de transport (taxis, trains, sociétés de location de voitures, etc.). Toutefois, celui-ci se concentre principalement sur les entreprises de transport et non sur les intermédiaires.
Description technique
Conception d’un modèle de données prototype (JSON) pour la Suisse
Ci-dessous, nous concevons un modèle de données pour un prototype de répertoire de services de mobilité. Celui-ci doit pouvoir restituer des métadonnées telles que l’URL, la description, les processus de distribution pris en charge. Le modèle doit fournir une base permettant d’entamer la discussion avec les acteurs et la communauté.
Specification by example
Notre projet est présenté ici à l’aide d’un jeu de données prototype exemplaire.
{
"last_updated": "2024-07-26T15:54:16.940281+00:00",
"ttl": 31536000,
"version": "0.1",
"spec": "https://opentransportdata.swiss/de/cookbook/service-directory",
"mobilityProviders": [
{
"id": "1",
"name": "SBB Swiss Mobility API - Ticketing",
"description": "An interface that you can integrate into your own distribution system. Fare details are made available to you via this interface.",
"type": "intermediary",
"endpoints": [
{
"url": "https://developer.sbb.ch/apis/b2p/information",
"environment": "prod",
"service_types": [
"pricing",
"reservation"
],
"api_protocol": "proprietary",
"api_version": "3.26.2",
"api_profile": "3.26.2/none",
"credentials": "BearerToken",
"url_description": "SBB Swiss Mobility API - Ticketing. An interface that you can integrate into your own distribution system. Fare details are made available to you via this interface.\nThere are two ways to use the service:\n- Either integrate the SBB Swiss Mobility API as a full version, so that bookings are made directly via your distribution environment\n- Or use the Affiliate solution, with a link to the SBB webshop or SBB mobile",
"qos_document": "https://developer.sbb.ch/apis/b2p/information",
"url_contractual": "https://company.sbb.ch/en/sbb-as-business-partner/services/digital-sales-solutions/sales-solutions/sbb-swiss-mobility-api/sbb-swiss-mobility-api-gtc.html",
"covered_modes": [
"rail",
"tram",
"bus",
"trolleybus",
"metro"
]
}
],
"myOpertors": [
{
"ref": "ch:1:sboid:100001",
"name": "Schweizerische Bundesbahnen SBB"
}
],
"otherOpertors": [],
"coveredArea": "CH"
},
{
"id": "101",
"name": "Open Journey Planner 2.0",
"description": "OJP is the API's Route Planner. The API can be used to plan trips, track journeys, and build departure and arrival indicators. OJP works from coordinate to coordinate, address to address.",
"type": "intermediary",
"endpoints": [
{
"url": "https://api.opentransportdata.swiss/ojp20",
"environment": "prod",
"service_types": [
"planning"
],
"api_protocol": "OJP",
"api_version": "2.0",
"api_profile": "none",
"credentials": "BearerToken",
"url_description": "unknown",
"qos_document": "https://data.opentransportdata.swiss/en/dataset/ojp2-0",
"url_contractual": "https://opentransportdata.swiss/en/dev-dashboard",
"covered_modes": [
"bus",
"coach",
"funicular",
"metro",
"rail",
"tram",
"trolleybus",
"water",
"cableway",
"taxi",
"bicycle",
"demand_and_response_bus",
"car",
"scooter",
"cable_car",
"telecabin",
"air_cableway"
]
}
],
"myOpertors": [],
"otherOpertors": [],
"coveredArea": "CH"
},
{
"id": "102",
"name": "OJPFare",
"description": "Beta: Price information with OJP Fares. A query of public transport prices via NOVA is made available via this interface. This is an initial test system and the data comes from integration and not from production.",
"type": "intermediary",
"endpoints": [
{
"url": "https://api.opentransportdata.swiss/ojpfare/",
"environment": "int",
"service_types": [
"pricing"
],
"api_protocol": "OJP",
"api_version": "1.0",
"api_profile": "none",
"credentials": "BearerToken",
"url_description": "unknown",
"qos_document": "https://opentransportdata.swiss/en/cookbook/beta-price-information-with-ojp-fares-2",
"url_contractual": "https://opentransportdata.swiss/de/dev-dashboard",
"covered_modes": [
"bus",
"coach",
"funicular",
"metro",
"rail",
"tram",
"trolleybus",
"water",
"cableway",
"taxi",
"bicycle",
"demand_and_response_bus",
"car",
"scooter",
"cable_car",
"telecabin",
"air_cableway"
]
}
],
"myOpertors": [],
"otherOpertors": [],
"coveredArea": "CH"
}
]
}
Modélisation sous forme de diagramme de classes UML
Structure de base
La structure de base est une liste (tableau) de tous les mobilityProviders connus. Dans les versions futures, une interface d’interrogation pourrait remplacer le fichier et permettre d’interroger les différents mobilityProvider en fonction de certaines caractéristiques.
MobilityProvider
MobilityProvider comprend des champs de base (caractéristiques simples) de celui-ci:
- id : identifiant ; repris autant que possible de répertoires établis (p. ex. sboid).
- orgId : identifiant issu du répertoire atlas.app.sbb.ch (inexistant pour les données d’exemple actuelles).
- type : Enum (plage de valeurs : provider, intermediary, providerAndIntermediary).
- coveredArea : voir plus bas.
S’y ajoutent les listes (tableaux, arrays) de endpoints, myOperators et otherOperators.
Endpoint (point de terminaison)
Endpoint définit une interface API concrète pour l’utilisation automatique. Remarques sur les champs (voir aussi Enums):
- apiVerision / apiProfile : version et (le cas échéant) expression du profil de la norme/du format d’interface.
- urlDescription / urlContractual /QoSDocument : URLs avec documentation correspondante (spécification & documentation / contractuelle / qualité de service)
- serviceType : Domaine de valeurs generalInfo, planning, availability, using, pricing, reservation, bookingLeg, bookingTrip, complaints, payment.
- apiProtocol : domaine de valeurs proprietary, TOMP, OJP, OSDM.
- coveredMode : Plage de valeurs air, bus, coach, ferry, funiculaire, ascenseur, métro, rail, tram, trolleybus, eau, cableway, moto, taxi, vélo, navette, demand_and_response_bus, horse_drawn_carriage, car, scooter, cable_car, telecabin, air_cableway, monorail, other. Correspond aux modes de NeTEx.
- credentials : Plage de valeurs BearerToken, OAuthSKI, OAuth, unknown.
Operator (opérateur)
myOperators et otherOperators référencent les fournisseurs soutenus ou associés (entreprises de transport); limité à l’id (ref) et au nom; les données supplémentaires devraient être externalisées dans une liste séparée.
coveredCountry / coveredArea
Ce champ dans MobilityProvider doit définir la couverture géographique. La solution suivante est proposée ici:
- Définition de zones géographiques (Areas) au moyen de Geofences avec des coordonnées WGS-84, externalisées dans un fichier GeoJSON séparé.
- Utilisation de FeatureCollections GeoJSON, définition de polygones/multipolgones.
- Référencement des abréviations usuelles et courantes, p. ex. CH pour la Suisse, abréviation de canton pour les cantons, etc.
- les géofences qui n’existent pas encore sont saisies à nouveau, avec l’abréviation appropriée.
Informations supplémentaires
Il s’agit actuellement d’un “projet alpha” destiné à la discussion et sans aucun caractère contraignant.
Commentaires bienvenus, à envoyer à opendata@sbb.ch.