GTFS Schedule beskriver den planlagte transporttilbud. GTFS Realtime, ofte kaldet GTFS-RT, formidler opdaterede serviceinformationer. GBFS beskriver dele-mobilitetstjenester, herunder stationer og tilgængelige køretøjer via offentliggjorte feeds. Vælg format ud fra hvilken problemstilling din applikation skal løse.
Disse formater organiserer data; de garanterer ikke tilgængelighed overalt eller kvaliteten af hver feed.
GTFS til at repræsentere det planlagte tilbud
Et GTFS Schedule-sæt samler tabeldatafiler der beskriver blandt andet operatører, stoppesteder, ruter, afgange og deres passager. Kalendere angiver hvilke dage der gælder. Filerne knyttes sammen via id'er. GTFS Schedule reference.
Det gør det muligt at besvare spørgsmål som „hvor er dette stoppested?“ eller „hvilken passage er planlagt for denne service?“. For at udnytte en tidsplan skal du fortolke kalenderen og sammenhænge mellem filer.
Det er derfor ikke nok kun at læse en liste over stoppesteder for at genskabe passagerne. Omvendt kan en positionsangivelse af et stoppested være nyttig uden at vise tidsplaner.
GTFS-RT til opdatering af serviceinformationer
GTFS Realtime kan levere opdateringer af afgange, køretøjspositioner og advarsler. Afgangsopdateringer vedrører passager og ændringer i service. Feeds bruger Protocol Buffers, et struktureret serialiseringsformat. Introduktion til GTFS Realtime.
En udbyder kan offentliggøre visse kategorier uden at levere alle andre. Tilstedeværelsen af en positions-feed garanterer ikke estimater for alle stoppesteder.
For brugerfladen bør du skelne mellem planlagt passage og det opdaterede estimat. Vores guide teoretiske og realtidsplaner forklarer denne forskel fra brugerens synspunkt.
GBFS til dele-mobilitet
GBFS bruger JSON-feeds til at beskrive en dele-mobilitetstjeneste. Afhængigt af systemet og versionen kan de angive stationer, deres status, køretøjer og andre servicens karakteristika. Dokumentationen skelner særligt mellem stationoplysninger og tilgængelighedsstater. GBFS-dokumentation.
Adskil i din applikation de relativt stabile placeringer fra de hurtigt skiftende tilgængelighedstilstande. Bevar versionsnummeret og den relevante tidsstempling ved fortolkning.
En tilgængeligheds-feed er ikke en API til reservation eller oplåsning. Den hjælper med at finde tilbud; selve udlejningen håndteres af den respektive tjeneste.
Sammenlign efter brugstilfælde
| Behov | Format der bør overvejes |
|---|---|
| Beskrive planlagte stoppesteder og ruter | GTFS Schedule |
| Fortolke planlagte passager og servicedage | GTFS Schedule |
| Opdatere passager eller modtage serviceoplysninger | GTFS-RT, afhængigt af udgivne feeds |
| Lokalisere stationer eller køretøjer til dele-mobilitet | GBFS, afhængigt af offentliggjorte data |
Designeksempel: et kort viser sporvognsstoppesteder og cykelstationer. Det bruger strukturelle data til lokationer og opdaterede statusser for cyklernes tilgængelighed. De to lag har forskellige behov for caching og opdatering.
Forudse begrænsningerne ved hver kilde
Kontroller versioner, valgfrie felter, dækning og brugsrettigheder. Et id giver kun mening i sin kontekst: to udbydere kan anvende identiske strenge til forskellige enheder.
Forbered dig også på manglende eller forældede data. En tom liste fra en utilgængelig feed bør ikke vises som fravær af service. Undgå at erstatte uvidenhed tavst med nul.
Brug direkte feeds eller en API
Direkte integration overlader ansvaret for at samle, validere og fortolke kilder til dig. En API kan tilbyde en fælles kontrakt, men du skal altid læse dens dækning, advarsler og betingelser.
For et første ROOTE-brugstilfælde, se hvordan man søger efter nærliggende stoppesteder med en API. Start med dit interfacebehov, og tjek dernæst de faktiske tilgængelige felter.
Læs uddrag og vælg en arkitektur
I GTFS Schedule forbinder et uddrag af stop_times.txt en kørsel, et stop og et planlagt passager. Det forenklede eksempel nedenfor er pædagogisk: det udgør ikke et komplet GTFS datasæt, og dets identifikatorer skal knyttes til trips.txt, stops.txt og kalendere.
For GTFS Realtime, søg efter den relevante enhed: en TripUpdate kan opdatere et passager, en VehiclePosition beskriver en position, og en Alert videregiver servicemeddelelser. En køretøjsposition er ikke automatisk et estimat af ankomsttid. Det overførte format er Protocol Buffers; en JSON-repræsentation til diagnosticering er ikke den binære referencestream.
I GBFS beskriver station_information stationerne, mens station_status beskriver deres offentlige status. Navne på visse tællere og tilgængelige filer varierer efter version. Det følgende JSON-uddrag illustrerer GBFS 2.3 og felterne num_bikes_available og num_docks_available; kontroller versionen, før du bruger et eksempel.
Et kort med lokaliteter kan starte med strukturelle data. En skærm med kommende afgange kræver derefter de tilsvarende opdateringer og en eksplicit planlagt back-up. En skærm med tilgængelige cykler skal håndtere tællere, lejevilkår og tidsmæssig validitet. Disse tre skærme deler ikke automatisk samme cache-politik.
# 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
}Formatering af cykeltilgængelighed og dens aktualitet
Vælg et API eller en MCP til dit produkt
Ofte stillede spørgsmål
Indeholder GTFS automatisk realtidsinformation?
Nej. GTFS Schedule repræsenterer det planlagte tilbud; opdaterede informationer leveres via andre feeds, især GTFS-RT.
Tillader GBFS at låse en cykel op?
Det beskriver servicen og dens offentlige data. Udlejning håndteres via operatørens muligheder.
Sikrer et standardformat fuld dækning?
Nej. Formatet definerer en struktur; dækning og offentliggjorte informationer afhænger af kilderne.