Megnéztem, végülis a "schedule-for-stop"-nak is lehet több stopId-t megadni.
Nem tudom melyik a jobb a BKK-nak, ha 8 API kérést küldök (4 metró, 4 hév) de baromi nagy választ kell visszaadjanak, vagy 124-et külön minden megállóra, amikre jóval kisebb választ kell küldeni.
Túl gyakran nem kell ez nekem, naponta egyszer kell lekérdezni, ezt akár előző nap is meg tudom tenni szépen lassan.
Nekem egyszerűbb lenne a futár API, mert akkor csak egy forrást kell kezelni, mert a HÉV-nél már van realtime data, meg ha esetleg a pótlóbuszok infóját is felhasználnám, zavarok, stb.
Mivel a metróknál amúgy sincs valós idejű adat, erre a GTFS lenne a leghatékonyabb, mert ott direktben hozzáférsz minden adathoz, amire szükséged van.
A FUTÁR API esetén, ha az arrivals-and-departures-for-stop lekérdezést használod, az fogad egyszerre több stopId-t is (?stopId=X&stopId=Y&stopId=Z formában), tehát ezzel lehet csökkenteni a lekérdezések számán. Azonban emlékeim szerint nem fogja ugyan azt a trip-et egy válaszban egynél többször visszaadni, tehát nem fogod tudni egyben lekérdezni az összes megállót 1-1 metróvonalon. Azt lehet, hogy egy lekérdezésben lekérdezed az M1-M2-M3-M4 első megállóját mindkét irányban (összesen 8 megállót), majd egy második lekérdezésben a második megállókat, stb. Így ha jól számolok, 20 lekérdezéssel megúszod.
A másik opció, hogy a végállomási menetrendeket kérdezed le (schedule-for-stop), majd utána minden aktuális trip megállóit egyenként (trip-details), de ez valamivel több lekérdezés lesz.
Köszi, közben meglett hogy BKK_H5/6/7/8/9 a routeId, nem a régi 6000-es ID-k vannak már.
Még egy olyan kérdésem lenne, hogy ha le szeretném kérdezni az összes metróállomás indulását, hogy egy saját kijelzőn tudjam vizualizálni, hogy melyik állomáson van éppen szerelvény, akkor van annál jobb opció, hogy minden megálló menetrendjét lekérem külön-külön?
Még mindig a BKK API-ban vannak, az utóbbi ~1 évben ez a helyzet:
A HÉV adatok továbbra is BKK GTFS állományában, a BKK GTFS-RT-ben és a BKK FUTÁR API-ban érhetőek el.
A HÉV pótlóbuszok szintén benne vannak a BKK FUTÁR API-ban, de nincsenek benne a BKK GTFS-ben és a GTFS-RT-ben. Helyette Volánbusz GTFS-ében érhetőek el (amikor épp elérhetőek), illetve elvileg a Volánbusz GTFS-RT-ben is szerepelnek (ami nem nyilvános).
A typescript fájlt az alábbi paranccsal generáltam a proto fájlból: protoc --plugin=protoc-gen-ts=/usr/local/lib/node_modules/ts-protoc-gen/bin/protoc-gen-ts --ts_out=typescript --proto_path=. ./*.proto
Korábban elérhető volt a GTFS adatbázis verzióinfója CSV formátumban ( https://bkk.hu/apps/gtfs/?mod=csv ), de az új OpenData portálon ez már nem működik. Van esetleg valami alternatíva amiből lehet tudni, hogy mikor frissült az adatbázis anélkül, hogy le kéne mindig töltögetni az egészet?
Annó én játszottam vele, én Microsoft Access-szel etettem meg, de nem teljesen triviális, hogy melyik mező mit tud, érdemes a fórumot (is) olvasgatni hozzá. Amúgy hihetetlen sok infó van benne, érdemes kiismerni.
Valóban, Én is keresem az okát. Egyenlőre nem jutottam válaszhoz. Gyaníthatóan a Budapest GO zavart be, bár indokolatlan. Talán sosem volt ilyen, hogy 14 napja nincs frissítés.
Az egyértelműség kedvéért, az API nem változik, csak bővül, és már élesben is van (ha használod, jelenleg is azt használod). A hozzáférés módja lesz szabályozott, de attól sem kell tartani - részletek akkor lesznek, amikor bejelentik.
Sajnos, mivel nem igazán van dokumentálva az API, így csak a mezők nevei maradnak dokumentációként, és nem egyszerű eligazodni több tízezer soros JSON-on.
A plan-trip.json válaszban van benne, ebben a konkrét példában a data.entry.plan.itineraries[0].legs[1].pathway jelölné, hogy lépcső-e az adott szakasz. Úgy tűnik, hogy ez valamiért most mindig false, viszont a data.entry.plan.itineraries[0].patternItineraries[0].legs[1].pathway már jól van beállítva. Valószínűleg csak ez utóbbit használja most már a frontend, a régi a visszafele kompatibilitás miatt maradhatott az API-ban (?).
Ha a GTFS-ből tervezel, akkor ott a pathways.txt fájl tartalmazza a releváns útvonalakat.
Arra a kérdésre keresem a választ, hogy milyen adatok alapján jeleníti meg a https://futar.bkk.hu alkalmazás a lépcsőket (pl. a metróról való leszállás után) ?
Az alábbi eset (HTTP request), a Gyöngyösi utca metrómegállóból (stopId=BKK_F02684), a Gyöngyösi utcára való gyalogláshoz (stopId=BKK_L008162) egy lépcső-megmászás-ikont tesz. De milyen adatok alapján ?
futar API kérdésem volna, azon belül Bubi: a bicycle-rental.json request visszaadja az összes BUBI állomást azzal az infóval, hogy hány bicikli érhető el éppen. Viszont az hogy hány hely van összesen, arra mindig 999-et ad. Ezzel szemben a Google Maps megmondja hogy pl. 8/19, azaz a 19 helyből 8-on van éppen bicikli. Feltételezem, hogy a Google is a BKK-tól veszi az adatot. Hogy tudnám ezt a futar API-val elérni?
Utána kerestem. Jogszabály szerint közérdekű adatigénylésnél meg kell adni a nevet és az elérhetőséget. Ezek szerint a BKK részéről csak gesztus, hogy külön igénylés nélkül elérhetővé teszi. Mondjuk a MÁV-nál meg a szvör érhető el külön igénylés nélkül.
Szerintem sem, de furcsa lenne azt a kritériumot alkalmazni, hogy hajlandó-e megadni valaki a személyes adatait. Ha mégis így van, akkor ezt az adatkezelési tájékoztatóban fel kellene tüntetni.
A honlapon elérhető Adatkezelési tájékoztatóból nem derül ki, hogy ebben az esetben mi lenne a személyes adatok kezelésének célja és jogalapja, úgyhogy ezekre érdemes rákérdezni csak úgy kíváncsiságból. A jogalapra mondhatják azt, hogy az adatok megadásával hozzájárulsz az adatkezeléshez, de az adatkezelés célja akkor is kérdéses. Nem kizárt, hogy itt sérül a célhoz kötöttség és adattakarékosság GDPR szerinti elve.
