Nem, a gtfs@mav-start.hu email címre írtam, valamint másolatként megadtam az eszrevetel@mav-start.hu -t is. Utóbbiról Én is a 30 napos bisszajelzést kaptam. Mindenesetre december 31 óta éppen a mai nap, január 6-án lett újra elérhető az eredeti máv-os hivatkozás. Ahogy látom az adatok minősége nem változott, teljesen azonos.
A gtfs@mavcsoport.hu címre írtál, vagy máshová? Én is kerestem őket a MÁV DIREKT-en keresztül (informacio@mav-start.hu), még január elsején, de csak a szokásos "30 napon belül válaszolunk" automatikus üzenet jött meg.
2025 január 2 éjjel óta nem műkdöik a MÁV hivatalos GTFS letöltési lehetősége. Írtam nekik emailt. Egyenlőre nem érkezett válasz. Amint ingen, jelezni fogom a válaszuk.
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 ?
