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.
Illetve mégegy kérdésem lenne: Példának vegyük a 2-es villamost Bécsi úttól Kelenföld felé. Itt csak arrival time van és nincs departure time. Hogyan kéne megszerezni / kiszámolni a departure time-ot is hozzá?
Most megint sikerült hülyeséget raknia a BKK-nak a GTFS állományba. Novemberre sok járatnál az októberi menetrendet hozza érvényesnek annak ellenére, hogy az adatbázis generálásakor már tudható volt, hogy novemberben a metrópótlás miatt változik a menetrend. Mégis beírták úgy, hogy novembertől újra a meglévő tanítási menetrend lesz érvényes, ahelyett, hogy üresen hagyták volna azokat a napokat az új menetrend elkészültéig.
