GTFS Schedule apraksta plānoto transporta piedāvājumu. GTFS Realtime, bieži saukts par GTFS-RT, nodod aktuālu informāciju par pakalpojumu. GBFS apraksta koplietojamās mobilitātes pakalpojumus, tostarp to stacijas un pieejamos transportlīdzekļus, atkarībā no publicētajiem plūsmām. Izvēlieties formātu, lai risinātu konkrētu jūsu lietotnes vajadzību.
Šie formāti organizē datus; tie negarantē to pieejamību visur vai katras plūsmas kvalitāti.
GTFS — plānotā piedāvājuma attēlošanai
GTFS Schedule kopa apvieno tabulas failus, kuros aprakstīti operatori, pieturas, maršruti, reisi un to pieturu laiki. Kalendāri norāda attiecīgās dienas. Faili ir saistīti ar identifikatoriem. GTFS Schedule atsauces informācija.
Tas ļauj atbildēt uz jautājumiem, piemēram, “kur atrodas šī pietura?” vai “kāds ir plānotais šī reisa laiks?”. Lai izmantotu grafiku, ir jāinterpretē kalendārs un failu attiecības.
Tātad pieturu saraksta vienkārša nolasīšana nav pietiekama, lai atjaunotu reisu laikus. Savukārt pieturas pozīcija var būt noderīga arī bez grafiku attēlošanas.
GTFS-RT — pakalpojuma informācijas atjaunināšanai
GTFS Realtime var nodrošināt reisu atjauninājumus, transportlīdzekļu pozīcijas un brīdinājumus. Reisu atjauninājumi attiecas uz pieturām un pakalpojumu izmaiņām. Plūsmas izmanto Protocol Buffers, strukturētas seriālizācijas formātu. GTFS Realtime ievads.
Producents var publicēt tikai konkrētas kategorijas, nenodrošinot visas pārējās. Transportlīdzekļu pozīciju plūsmas esamība negarantē aplēses visām pieturām.
Lietotāja interfeisā atšķiriet plānoto pieturu laiku no aktuālā vērtējuma. Mūsu ceļvedis teorētiskie un reāllaika grafiki skaidro šo atšķirību no lietotāja skatupunkta.
GBFS koplietojamai mobilitātei
GBFS izmanto JSON plūsmas, lai aprakstītu koplietojamas mobilitātes pakalpojumu. Atkarībā no sistēmas un versijas tās var saturēt datus par stacijām, to statusu, transportlīdzekļiem un citām pakalpojuma īpašībām. Dokumentācija izšķir staciju informāciju un pieejamības statusus. GBFS dokumentācija.
Lietojumprogrammā atdaliet relatīvi stabilās vietas no ātri mainīgajiem statusiem. Saglabājiet formatējuma versiju un atbilstošo laika zīmogu interpretējot datus.
Pieejamības plūsma nav rezervēšanas vai atslēgšanas API. Tā palīdz atklāt piedāvājumu; noma ir attiecīgā pakalpojuma kompetencē.
Salīdziniet pēc lietošanas gadījuma
| Nepieciešamība | Pārbaudāmais formāts |
|---|---|
| Aprakstīt plānotās pieturas un maršrutus | GTFS Schedule |
| Interpretēt plānotos reisus un dienas, kad pakalpojums darbojas | GTFS Schedule |
| Atjaunināt reisu laikus vai saņemt pakalpojuma informāciju | GTFS-RT, atkarībā no publicētajām plūsmām |
| Noteikt koplietojamās mobilitātes stacijas vai transportlīdzekļus | GBFS, atbilstoši publicētajiem datiem |
Dizaina piemērs: karte rāda tramvaja pieturas un velosipēdu stacijas. Tā izmanto strukturētus datus atrašanās vietām un aktuālos statusus velosipēdu pieejamībai. Abām slāņiem ir dažādas vajadzības kešēšanā un atjaunināšanā.
Plānojiet katra datu avota ierobežojumus
Pārbaudiet versijas, izvēles laukus, pārklājumu un izmantošanas tiesības. Identifikatoram ir nozīme tikai savā kontekstā: divi producenti var izmantot vienādas virknes dažādām vienībām.
Ņemiet vērā arī trūkstošos vai novecojušos datus. Tukšs saraksts no nepieejamas plūsmas nedrīkst tikt attēlots kā pakalpojuma neesamība. Izvairieties klusējot aizstāt zināmo informācijas trūkumu ar nulli.
Izmantot plūsmas tieši vai API
Tieša integrācija atstāj jums atbildību vākt, validēt un interpretēt avotus. API var piedāvāt kopīgu līgumu, bet jums vienmēr jāpārbauda tā pārklājums, brīdinājumi un nosacījumi.
Pirmajam ROOTE lietošanas gadījumam skatiet kā meklēt tuvākās pieturas ar API. Sāciet ar savas saskarnes vajadzību un pārbaudiet patiesi pieejamos laukus.
Lasīt fragmentus un izvēlēties arhitektūru
GTFS Schedule gadījumā stop_times.txt fragments saista reisu, pieturu un plānoto pieturēšanos. Zemāk redzamais saīsinātais piemērs ir mācību nolūkos: tas nav pilnīgs GTFS datu kopums, un tā identifikatori jāsaista ar trips.txt, stops.txt un kalendāriem.
GTFS Realtime gadījumā meklējiet noderīgo vienību: TripUpdate var atjaunināt pieturēšanos, VehiclePosition apraksta transportlīdzekļa atrašanās vietu, bet Alert nodod pakalpojuma informāciju. Transportlīdzekļa atrašanās vieta automātiski nav ierašanās laika prognoze. Pārsūtītais formāts ir Protocol Buffers; diagnostikas JSON attēlojums nav atsauces binārais datplūsma.
GBFS gadījumā station_information apraksta stacijas, savukārt station_status — to publiskotos statusus. Dažu skaitītāju nosaukumi un pieejamie faili mainās atkarībā no versijas. Zemāk redzamais JSON fragments ilustrē GBFS 2.3 versiju un tā laukus num_bikes_available un num_docks_available; pirms pieņemšanas pārbaudiet versiju.
Vietu karte var sākties ar strukturālajiem datiem. Nākamo pieturēšanos ekrānam nepieciešami atbilstoši atjauninājumi un skaidri plānota nokrišana. Pieejamo velosipēdu ekrānam jāapstrādā skaitītāji, nomas nosacījumi un laika derīgums. Šie trīs ekrāni automātiski neseko vienai kešatmiņas politikai.
# 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
}Formatēt velosipēdu pieejamību un tās svaigumu
Izvēlēties API vai MCP jūsu produktam
Bieži uzdotie jautājumi
Vai GTFS automātiski satur reāllaika datus?
Nē. GTFS Schedule attēlo plānoto piedāvājumu; aktuālā informācija ir citās plūsmās, tai skaitā GTFS-RT.
Vai GBFS ļauj atslēgt velosipēdu?
Tas apraksta pakalpojumu un tā publiskos datus. Nomas process notiek caur operatora piedāvātajām iespējām.
Vai standarta formāts garantē pilnīgu pārklājumu?
Nē. Formāts definē struktūru; pārklājums un publicētā informācija ir atkarīga no avotiem.