| Alpha Prototype — Feedback Welcome! |
Descrizione della radice
Le directory di servizi di mobilità sono directory di servizi (API) che supportano la pianificazione e la prenotazione di viaggi. Tali elenchi giocano un ruolo fondamentale negli scenari per la messa in rete internazionale della mobilità, per il MaaS (Mobility as a Service) e per gli assistenti basati sull’intelligenza artificiale. Tuttavia, gli standard e i protocolli per questo sono ancora poco definiti.
Con questo articolo vorremmo contribuire allo sviluppo e alla standardizzazione di questo settore.
Descrizione speciale
Che cos’è una directory di servizi di mobilità?
Una directory di servizi di mobilità è una directory elettronica, leggibile a macchina (anche “catalog”, “registry”, “yellow pages”) di servizi (principalmente API) nel campo della mobilità. Supporta la ricerca di fornitori (intermediari, broker) con le loro interfacce di pianificazione e vendita (API). È quindi fondamentale per la pianificazione di viaggi intermodali in più parti, compresi i prezzi e la successiva prenotazione (prenotazione, acquisto, pagamento, compensazione).
Perché abbiamo bisogno di questi elenchi di servizi?
Attualmente stiamo assistendo a questi argomenti:
- Regolamento UE: il regolamento MMTIS dell’UE richiede ai PAN di fornire determinati set di dati. Nell’allegato sono definite circa 73 categorie di dati. Alcune di queste potrebbero essere organizzate sotto forma di elenco. Le disposizioni di attuazione precise sono attualmente (primavera 2024) in fase di elaborazione in un WG 3 di NAPCORE (con la partecipazione del nostro team SKI+).
- Vision MaaS (Mobility as a Service): gli elenchi di servizi sono necessari per creare un sistema MaaS internazionale, interoperabile e con capacità di roaming. Solo grazie a una directory un cliente in roaming (ad esempio un utente MaaS dall’estero) può trovare i servizi disponibili.
- Assistenti personali/agenti basati sull’intelligenza artificiale: secondo le previsioni di Gartner e di altri fornitori di analisi del mercato IT, tra qualche anno molti acquisti saranno effettuati da assistenti o agenti basati sull’intelligenza artificiale. Le persone chiedono alla loro IA, ad esempio, “Come posso viaggiare da A a B?” e “Prenotami questo viaggio!”. Ciò richiede elenchi strutturati di fornitori di mobilità.
Stato attuale dell’attuazione
Secondo le nostre osservazioni, tali progetti sono ancora agli inizi. In molti Paesi, tali elenchi non sono noti come dati aperti. Manca anche la standardizzazione dei formati e dei processi dei dati. Non siamo a conoscenza di norme in materia a livello europeo (CEN) o mondiale (ISO).
Vale la pena di citare l’esempio della Finlandia (NAP della Finlandia, https://finap.fi/#/services) con un elenco di oltre 3000 servizi di trasporto (taxi, treni, noleggio auto, ecc.). Tuttavia, questo si concentra principalmente sulle aziende di trasporto e non sugli intermediari.
Descrizione tecnica
Progettazione di un modello di dati prototipico (JSON) per la Svizzera
Di seguito, progettiamo un modello di dati per un prototipo di directory di servizi di mobilità. Dovrebbe essere in grado di visualizzare metadati come l’URL, la descrizione e i processi di vendita supportati. Il modello intende fornire una base per avviare la discussione con gli stakeholder e la comunità.
Specification by example
Il nostro progetto sarà presentato qui utilizzando un set di dati esemplare e prototipico.
{
"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"
}
]
}
Modellazione come diagramma di classe UML
Struttura di base
La struttura di base è un elenco (array) con tutti i mobilityProviders conosciuti. Nelle versioni future, un file potrebbe essere sostituito da un’interfaccia di interrogazione che consenta di interrogare i singoli mobilityProvider in base a caratteristiche specifiche.
MobilityProvider
MobilityProvider include i campi di base (caratteristiche semplici) dello stesso:
- id: Identificatore; tratto da elenchi consolidati, ove possibile (ad esempio, sboid).
- orgId: identificativo della directory atlas.app.sbb.ch (non esiste per i dati del campione attuale).
- tipo: Enum (intervallo di valori: provider, intermediario, providerAndIntermediary).
- coveredArea: vedere sotto.
Inoltre, ci sono gli elenchi (array) di endpoints, myOpertors e otherOperators.
Endpoint (punto finale)
Endpoint definisce un’interfaccia API specifica per l’uso automatico. Note sui campi (vedere anche Enum):
- apiVerision / apiProfile: versione e (se applicabile) versione del profilo dello standard/formato dell’interfaccia.
- urlDescription / urlContractual /QoSDocument: URL con la documentazione corrispondente (Specifica e Documentazione / Contractual /Quality of Service)
- serviceType: gamma di valori generalInfo, pianificazione, disponibilità, utilizzo, prezzi, prenotazione, bookingLeg, bookingTrip, reclami, pagamento.
- apiProtocol: intervallo di valori proprietario, TOMP, OJP, OSDM.
- coveredMode: intervallo di valori aereo, autobus, pullman, traghetto, funicolare, ascensore, metropolitana, ferrovia, tram, filobus, acqua, funivia, moto, taxi, bicicletta, navetta, bus a chiamata, carrozza a cavalli, auto, scooter, funivia, telecabina, funivia, monorotaia, altro. Corrisponde alle modalità di NeTEx.
- credenziali: intervallo di valori BearerToken, OAuthSKI, OAuth, sconosciuto.
Operator
myOperators e otherOperators si riferiscono a fornitori supportati o associati (aziende di trasporto); si limitano a id (ref) e nome; ulteriori dati dovrebbero essere esternalizzati in un elenco separato.
coveredCountry / coveredArea
Questo campo di MobilityProvider è utilizzato per definire la copertura geografica. Si propone la seguente soluzione:
- Definizione di aree geografiche mediante geofence con coordinate WGS-84, memorizzate in un file GeoJSON separato.
- Uso di GeoJSON FeatureCollections, definizione di poligoni/multipoligoni.
- Riferimento alle abbreviazioni standard di uso comune, ad esempio CH per la Svizzera, abbreviazioni cantonali per i cantoni, ecc.
- Le geofirometrie che non esistono ancora vengono registrate con l’abbreviazione appropriata.
Ulteriori indicazioni
Si tratta attualmente di una “bozza alfa” da discutere e non è vincolante.
Il feedback è gradito, si prega di inviare a opendata@sbb.ch.