GTFS Schedule beskriver den planerade trafiklösningen. GTFS Realtime, ofta kallat GTFS-RT, förmedlar uppdaterad information om tjänsten. GBFS beskriver delade mobilitetstjänster, inklusive deras stationer och tillgängliga fordon enligt publicerade flöden. Välj format utifrån vilken fråga din applikation behöver lösa.
Dessa format organiserar data; de garanterar varken tillgänglighet överallt eller kvaliteten på varje flöde.
GTFS för att representera den planerade trafiken
En GTFS Schedule-sats samlar tabellfiler som beskriver bland annat operatörer, hållplatser, linjer, turer och deras avgångar. Kalendrar anger berörda dagar. Filerna kopplas samman med identifierare. GTFS Schedule referens.
Det kan besvara frågor som ”var ligger denna hållplats?” eller ”vilken avgång är planerad för denna tjänst?”. För att använda ett tidsschema måste du tolka kalendern och relationerna mellan filerna.
Att bara läsa en lista över hållplatser räcker alltså inte för att rekonstruera avgångarna. Däremot kan en hållplatsposition vara användbar utan att visa tidtabeller.
GTFS-RT för att uppdatera tjänsteinformation
GTFS Realtime kan tillhandahålla uppdateringar av turer, fordonspositioner och varningar. Turuppdateringar gäller bland annat avgångar och tjänsteförändringar. Flödena använder Protocol Buffers, ett strukturerat serialiseringsformat. Introduktion till GTFS Realtime.
En producent kan publicera vissa kategorier utan att tillhandahålla alla andra. Närvaron av ett positionsflöde garanterar inte uppskattningar för alla hållplatser.
För gränssnittet, gör skillnad mellan planerad avgång och uppdaterad uppskattning. Vår guide teoretiska tidtabeller och realtid förklarar denna skillnad från användarens perspektiv.
GBFS för delad mobilitet
GBFS använder JSON-flöden för att beskriva en delad mobilitetstjänst. Beroende på system och version kan de ge information om stationer, deras status, fordon och andra egenskaper hos tjänsten. Dokumentationen skiljer särskilt på stationsinformation och tillgänglighetsstatus. GBFS-dokumentation.
Separera i din applikation stationer med relativt stabil position från snabbt föränderliga statusar. Behåll versionsnummer på formatet och relevant tidsstämpel vid tolkning.
Ett tillgänglighetsflöde är inte ett boknings- eller upplåsnings-API. Det hjälper till att upptäcka erbjudandet; själva uthyrningen hanteras av den berörda tjänsten.
Jämför efter användningsfall
| Behov | Format att granska |
|---|---|
| Beskriva planerade hållplatser och linjer | GTFS Schedule |
| Tolka planerade avgångar och servicdagar | GTFS Schedule |
| Uppdatera avgångar eller få serviceinformation | GTFS-RT, beroende på publicerade flöden |
| Lokalisera stationer eller delade mobilitetsfordon | GBFS, beroende på publicerade data |
Designexempel: en karta visar spårvagnshållplatser och cykelstationer. Den använder strukturella data för platser och uppdaterade statusar för cyklarnas tillgänglighet. De två lagren har olika behov av cache och uppdatering.
Förutse begränsningar för varje källa
Kontrollera versioner, valfria fält, täckning och användningsrättigheter. Ett identifierare är bara meningsfullt i sitt sammanhang: två producenter kan använda identiska strängar för olika enheter.
Förutse också saknade eller föråldrade data. En tom lista från ett otillgängligt flöde ska inte visas som en frånvaro av tjänst. Undvik att tyst ersätta okänd information med noll.
Använda flöden direkt eller via ett API
En direkt integration ger dig ansvar för att samla in, validera och tolka källorna. Ett API kan erbjuda ett gemensamt kontrakt, men du måste alltid läsa dess täckning, varningar och villkor.
För ett första ROOTE-användningsfall, se hur man söker hållplatser i närheten med ett API. Börja med behovet för ditt gränssnitt och kontrollera sedan vilka fält som faktiskt finns tillgängliga.
Läsa utdrag och välja en arkitektur
I GTFS Schedule länkar ett utdrag från stop_times.txt en tur, en hållplats och en planerad passage. Det nedanstående förkortade exemplet är pedagogiskt: det utgör inte ett komplett GTFS-spel och dess identifierare måste kopplas till trips.txt, stops.txt och kalendrar.
För GTFS Realtime, leta efter den relevanta enheten: en TripUpdate kan uppdatera en passage, en VehiclePosition beskriver en position, och en Alert förmedlar en servicemeddelande. En fordonsposition är inte automatiskt en ankomstprognos. Det överförda formatet är Protocol Buffers; en JSON-representation för diagnos är inte den binära referensströmmen.
I GBFS beskriver station_information stationerna medan station_status beskriver deras publicerade tillstånd. Namnen på vissa räknare och tillgängliga filer ändras beroende på version. JSON-utdraget nedan illustrerar GBFS 2.3 och dess fält num_bikes_available och num_docks_available; kontrollera versionen innan du använder ett exempel.
En karta över platser kan börja med strukturella data. En skärm för kommande passager kräver sedan motsvarande uppdateringar och en uttryckligen planerad fallback. En skärm för tillgängliga cyklar måste hantera räknare, uthyrningsvillkor och tidsmässig giltighet. Dessa tre skärmar delar inte automatiskt samma cachepolicy.
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1
# Extrait pédagogique de station_status en GBFS 2.3
{
"station_id": "station_demo",
"num_bikes_available": 3,
"num_docks_available": 7,
"is_installed": true,
"is_renting": true,
"is_returning": true,
"last_reported": 1720000000
}Formattera cykeltillgänglighet och dess aktualitet
Välja ett API eller en MCP för din produkt
Vanliga frågor
Innehåller GTFS automatiskt realtidsdata?
Nej. GTFS Schedule representerar den planerade trafiken; uppdaterad information hanteras av andra flöden, bland annat GTFS-RT.
Kan GBFS låsa upp en cykel?
Den beskriver tjänsten och dess offentliga data. Uthyrning sker via kapaciteter som erbjuds av operatören.
Garantierar ett standardformat fullständig täckning?
Nej. Formatet definierar en struktur; täckning och publicerad information beror på källorna.