most kezdtem el nézegetni a bkk gtfs db-jét.. meg tudná esetleg nekem valaki mondani, hogy az pld, hogyan lehet, hogy a stops táblában, van egy csomó olyan stop_id amihez nem tartozik sor a stop_times táblában..
Egyszer végigpróbálgattam a ForTe-ban pár lehetőséget, hogy az utolsó (4.) számjegy vajon hogyan alakulhat, mint jelentenek az egyes számjegyek. Érdekes volt, na. :)
Ha arra a vonalra vezényelnek, oda lesz írva majd a forgalmi munkalapra, vagy megmondja a diszpécser, hogy mit írj be ;)
----
Az az azonosító, amit korábban forte kódként ismertünk, most már sokkal lazább rendszerben működik. Ez abból is látszik, hogy nem csak számokból áll és nem csak négy karakter hosszú lehet. A mostani rendszerben az általánosan elfogadott az, hogy a villamospótló VP-vel kezdődik és két vagy három számjeggyel folytatódik (szükség esetén a számsor balról nullával feltöltve).
Pl.:
VP06 6-os pótló
VP12 12-es pótló
VP46 4-6 pótló
VP145 14E jelzésű pótló
Az utolsó nyilván egy kicsit kakukktojás a jelzését tekintve, de az említett logika tökéletesen ráhúzható.
Ha háromnál több számjegy van az azonosítóban, akkor az a plusz számjegy általában a P betű rovására van ott.
Pl.:
VP4749 V4749
Ha pedig a gyorsvasúti hálózaton van pótlás, akkor az adott ágazathoz tartozó betűvel helyettesítik a villamosra utaló V-t. HÉV esetén H, metró esetén M. Ez egészül ki a pótlásra utaló P betűvel és az adott vonal azonosítójának első két számjegyével.
M4 (5400) -> MP54
H5 (6400) -> HP64
Az egy másik kérdés, hogy a HÉV-ek azonosítója miért olyan, amilyen. Fura, hogy a H5, nem lett a számosításkor 6500, de ez már nem ide tartozik.
A pótlások mellett egy általános logika mentén megy a nosztalgia járatok azonosítóval ellátása is.
A J betű alapján nehéz lenne megtalálni az azonosítók között, viszont az alapján, hogy a 2-es vonalán közlekedő nosztalgia villamosról van szó, egyértelművé válik, hogy miért 3027 az azonosítója.
Általánosan elmondható, hogy a nosztalgia járat, az útvonalon közlekedő alapjárat kódját kapja meg 7-es számmal az alapjárati 0 helyett.
Pl.:
E (körtér <> Kamaraerdő) -> 3417
Van persze kivétel is a nosztalgia rendszerben, mint mindenhol. Az ST jelzéssel közlekedő "városnéző" troli, mintha 4ST7 azonosítót kapott volna.
A viszonylatok kiírásánál hiányosan jelennek meg a forgalmik. Ha belemegyek a viszonylatba, akkor már jó, de pl. a 157-esnél még akkor is csak mára és tegnapra. Az ennél régebbinél az 1-es 3-as forgalmik teljesen hiányoznak, illetve hétvégére is csak a 2-eset mutatja.
Köszi, jó tudni. Akkor elvben előfordulhat olyan eset is, hogy egyáltalán nincs V az elején, ha valami hosszabb számpáros lenne adott esetben (pl. XXYYY), és akkor automatikusan nem is lehet megállapítani, hogy villamospótló az id alapján.
De, villamospótló. Nincs ilyen szabály, hogy VP-vel kéne kezdődnie, az ehhez hasonló esetekben mindig lehagyják a P-t, hogy ne legyen 5 karakternél hosszabb.
Az adatbázisban a V4749 nem villamospótló busz? Ha igen, akkor nem VP-vel kellene kezdődnie az id-nak, mint a többi villamospótlónál? Erre van valami szabály?
Korábban az éjszakai 6-os pótlót mintha láttam volna fekete háttérszínnel a GTFS-ben. Nem lenne több értelme most is feketével jelölni, ha a 4-6-ossal ellentétben csak éjszaka jár?
Usere válogatja. Szerintem a többség nem erre számít, nem ezt szokta meg, nem ezt látja át, esetleg a nevet sem tudja, hanem csak felismeri a környezetében. A Gyöngyösi utca nem a G betűnél van hanem az újpesti végállomás közelében.
Namost ha megállóból való indulásra vagyunk kíváncsiak, megteszi egy ABC-be rendezett lista is az összes, adott viszonylatnál előforduló megállóból. A user úgyis név alapján keresi a megállót.
Máshogy nem igazán lehet kiszűrni a csonkákat, legfeljebb statisztikai alapon: a két leggyakoribb megállólista a normál menetek két iránya, a többi csonka. Ezen elmélet borul a H6-os hévnél és a giga hosszú éjszakaiaknál is valószínűleg (956-990), ettől függetlenül jó elv.
Egyébként a bkk_ref oszlopok nem hordoztak plusz infót? Mintha arról lett volna szó régebben itt, hogy a csonkameneteket azokkal lehet megkülönböztetni a rendes menetektől, hogy van-e bkk_ref oszlop vagy nincs. Ki lehet ezt deríteni máshonnan is?
Ez az oszlopsorrend-probléma furcsa, hiszen ott van minden fájlban a csv header, onnan nehéz eltéveszteni, hogy melyik oszlop melyik, hacsak nem hibás a csv header.
Ami engem anno megszivatott, az az oszlop sorrend, ami a GTFS specifikáció szerint nem kötött. Ennek megfelelően a futárosban vannak sorrendbeli különbségek, így a feldolgozás során erre figyelni kell. Nyilván elég egyszer, hiszen csak az előző és a futáros feed között van különbség, a futáros verziók már konzekvensek.
A többi adat valóban többlet, így problémát nem okozhatnak. A bkk_ref oszlopokat pedig remélem, senki nem használta, nem sikerült megbízható adatokkal feltölteni...
