F betűvel jellemzően a régóta létező megállók kódja kezdődik, ezeket ugyanis eredetileg még a ForTe előtt használt informatikai rendszerben vették fel. Nincs különösebb jelentése, jelentősége.
Akkor az önmagában nem számít, hogy az adott telephely területén jelentkezik be? Mondjuk Af-ön tényleg előfordulhat, hogy menetirányváltás nélkül mozog végig a kocsiszínben, így a másik vége nem is aktiválódik a kocsiszínen belül.
A beállásokat nézi, tehát ha egy szerelvény mindig az egyik kocsijával áll be az új kocsiszínbe, akkor a másikat addig nem tudja áthelyezni amíg azzal is be nem állnak oda egyszer. Emiatt többkocsis szerelvények esetén van egy kis delay.
A winmenetrend oldalon mennyire megbízható a telephely információ? Mert elvileg az utolsó pozíció alapján generálja, de néha látok olyat, hogy a Tátra szerelvény egyik fele Angyalföldes, a másik fele meg Barossos, ami fizikailag lehetetlen.
Végtelenül gyorsan férhetnél hozzá ilyen adatokhoz nulla adatbázis használattal. Ott vannak a célállomások, lejjebb pedig a megállóneveket is megtalálod a fortekódokhoz.
Nem egy 150 megás adatbázison rágja át magát a rendszer, hanem egy pár tíz kilobájtos JSON állományon.
Ilyet a GTFS közvetlenül nem tartalmaz. A vonalakhoz nem tartoznak útvonalak, csak menetek, amik bármilyen útvonalon mehetnek. Egy vonal által érintett megállókat úgy kaphatod meg, hogy megnézed az egyes menetei milyen megállókat érintenek (ez utóbbi a stop_times.txt-ben szerepel). De ajánlom a referenciát.
Lehet, hogy többre jutsz, ha az utazástervező apiból kérdezed le és a kapott JSON objektumot dolgozod fel. Ha aktuális adatokra van szükséged, nem vesztesz semmit, viszont sok időt megtakarítasz.
Most így ránézésre nem tudom milyen nyelv, de gondolom az adatbázishoz kapcsolódás nem okoz gondot.
Ha viszonylatszámból akarsz megállókat, akkor minimum a trips, stop_times, stops táblákat össze kell kapcsolni. De ha azt akarod, hogy ez emberi időben lefusson, akkor először szűrnöd kell a trips táblát, különben a táblák Descartes szorzata kb. 5 000 000 x 200 000 x 2000 lesz, ami 2000 billió, azaz 2 x 10^15 sor végigbogarászását jelenti a lekérdezés számára. Belátható, hogy előszűrés nélkül nem kivitelezhető a JOIN.
Most így hirtelen nem tudom a továbbiakat, de ezzel a három táblával kell variálnod.