Szolgáltatótól függetlenül, közel minden esetben igaz az az állítás, hogy a járatok tervezésében családokat, csoportokat hoznak létre. Több esetben mindez transzparens, azonban sok fontos relációt rejtenek ezek a kivitelezések. Egy járathoz könnyedén kapcsolódhat egy pótló járat, - mely a hivatalos szakaszt hivatott kisegíteni, avagy olykor azonos megnevezéssel több járat is létezhet. Ez utóbbira Budapesten találunk kézenfekvő példákat. Az M3-as metró felújításakor volt idő, mikor 3 további önálló járat pótolta a szülő járatot, és a H5, H6 és a H8-as hév járatokból minimum 2 létezik. A csoport alkotásnak jellemzően semmilyen informatikai vetülete nincs, mely kapcsolatot definiál az említettekhez. Mindezek mellett további érintettséget lehet megfigyelni Pécsen, ahol több járat régió alapon hasonul a másikhoz, esetleg a konkrét párjához, mindezt úgy, hogy teljesen külön névvel rendelkeznek, például a 41 és 42-es járatok. A rendszerünk ezek felderítésében kidolgozott számításokat végeznek a részletesebb ismeretekért.

Teljesen életszerű, hogy egy megállóból több, esetenként sok létezik. Egy megállónak gyakorta esetben minimum van egy párja, mely az út két oldalát jelenti. A sok esete viszont már csomópontot illet, ahol akár 8-10 azonos névvel ellátott, - különböző koordinátára mutató, megálló van. A közlekedő tömeg szemszögéből senki nem fog azzal foglalkozni, hogy koordinátára pontosan válasszon ki egy adott megállót, hogy ő márpedig innen szeretne útvonaltervet tekinteni. Az azonos megállóhalmazokra vetülő csoportosítás bonyolultságát tovább komplexizálja, hogy sokszor annak ellenére, miszerint a halmazba tartozhatna, nem tud oda kerülni, mivel a megálló neve egy ki/lejáratot hordoz magában és/vagy további helyszín jelölést kapott. Erre két példa: "Blaha Lujza tér [A]" vagy "Örs vezér tere M+H". Mint az látható az "[A]" és az "M+H" teljes mértékben hasznos, de többlet információ a csomópont számítást illetően. A legdagasztottabb megállók közé sorolható az Örs vezér tere, melyből nem kevesebb, mint 45db önálló megálló létezik. A rendszerünk ezek összevonásában is kiemelt gondossággal jár el, hogy könnyebben lehessen illusztrálni a csomóponthoz tartozó menetrendeket.

Az utóbbi esztendökben egyre kacifántosabban közlednek a járatok. Az üzemeltetők szakítottak azzal a klasszikus hagyománnyal, hogy egy járatnak 1db oda és 1db vissza iránnyal szabad rendelkeznie. Napjainkra egy járatnak akár 6-8 különböző útvonala is létezhet, miszerint néha így, néha úgy közlekedik. Az alapértelmezett GTFS formátum sajnos nem ismerteti részletesen, ráadásul opcionálissá teszi az adott járathoz tartozó irányok jelenlétét. A rendszerünk nem csupán ezeket fejti vissza, hanem az irányokon belüli al-vonalaknak is pontos definíciót határoz. Mindemellett megállapításra kerülnek az útvonalak technikai értelembe vett szülei, valamint azok kapcsolt gyerekei is. Ezek a számítások nélkül elképzelhetetlen lenne illusztrálni, hogy hol és hogyan közlekednek a járatok. Prezentálási értelemben ez a komplex számításunk teremti meg a megállóválasztót, mint funkcionális kötelességet.

A generált útvonalak létezése az algoritmusaink legmagasabb szintjeit képzik. Egy menetrend szerinti járatnak sok nyomvonala létezhet, mely alapvetően hasonló, de semmiképp nem azonos. Jellemző esetben néha kihagy egy megállót, olykor csak egy bizonyos megállóig közlekedik, néha egy bizonyos megállóból indul, avagy délután 3 felé behajt még egy további utcába. Az utóbbiak szerint azt lehet feltételezni, hogy mindig van egy alapértelmezett fő nyomvonal és ehhez mérten léteznek a speciálisak. Egy járat által használt útvonal manapság elég dinamikus, mely ugyanígy igaz az általa igénybe vett megállókra is. A kedves utasok fejében döntő többségben kettő útvonal létezik, melyek a leggyakrabb esetekre igazak. Ezek általában az oda-vissza irányokat és a járat fix megállóit illetik. Amikor a felhasználó menetrendet tervez, akkor az utóbbi gondolatment szerint kell azt az informatikának illusztrálnia. Miszerint például Budapesten a HÉV-eknek olykor 7-8 útvonala van. mindezt nem lehet a felhasználók elé ömleszteni, hogy tessék válassz magadnak megfelelőt és vonj differenciát, hogy melyikre van szükséged, míg ezek 90%-ban azonosak. Egy megtett viszonylathoz számos további adat társul, ilyen a megtett szekvencia is. Csúcs időben lassabban tesz meg egy busz két megálló közti távolságot, míg hajnalban vagy este hamarabb tud a célba érni. A rendszerünk ezen a ponton kezd el igazán gondolkodni, hogy miképp tudja a számtalan útvonallal rendelkező járatnak kiszámítani a fő nyomvonalait. A generálás itt nyer igazán teret magának, mivel a számítás eredménye olykor fiktív, és többé nem egy bizonyos járat megtett viszonylatát prezentálja, hanem a lehetséges maximum adatot vizualizálja, a megfelelő dinamikus szekvenciában a közlekedő utas felé.

Szemrevételezve nem tűnik fel, azonban sok esetben redundánsan vannak tárolva a nyers adatok egy GTFS adatbázisban. A duplikáltan tárolt adatok teljesen feleslegesek, melyek helyenként csak megnehezítik a végtelen rekordok átláthatóságát. A rendszerünk már a belépési pontnál egyszerűsíti ezeket a szükséges-rossz adatokat. Ezzel a szűréssel érdemi fájlmért csökkenést lehet elérni, valamint sokat segít a hosszútávú tesztelés egyértelműsítésén is.

A publikum számára biztosított GTFS állományok sok esetben hiányosak, pontatlanok vagy kevesek. Például Pécsett a közlekedési napokat tartalmazó naptár régóta teljesen hibásan kerül publikálásra. Mindezt mi automatizáltan korrigáljuk a hivatalos szerv oldaláról lekérdezve, ezzel alternatív utat választva, hogy helyes adatokkal rendelkezzünk. Avagy említésre méltó a WeekendBus által kiadott GTFS, ahol a járat fizikai nyomvonalai teljes hiányosak. Továbbá Szegeden nem minden járatnál definiálták annak hosszú nevét. Ilyen kis kiemelten fontos apróságokból több is van. melyet a rendszerünk minden esetben sikeresen korrigál.

Az orientált fejlesztés fókuszpontja minden esetben az univerzális mobilvilág felé irányzott. Ez azt jelenti, hogy míg egy weboldal teljesítménye a szülőszervertől függ, - mely szabadon skálázható, addig a mobilok teljesen eltérő erőforrás kapacitással rendelkeznek. Ameddig a felhasználó eljut a járat menetrendi oldalára, addig sok-sok komplex lekérdezés történhet. Ezekben az esetekben sem fér bele, hogy 100-200ms legyen egy részteljesítés. Egy felhasználói bejelentkezés kapcsán vizuálisan megszokott élmény, hogy olykor várni kell 1-2 másodpercet. Itt azonban ez nem elfogadott. Ezen oknál fogva arra terveztük az adatbázist, hogy minden lekérdezés 5-10ms környékén legyen és egy pillanat alatt lehessen hozzáférni az igényekhez.

Ameddig nem veszed észre a hiányosságokat, addig az csak mást fog zavarni. Könnyedén megfigyelhető a közlekedési vállalatok weboldalán, hogy ők, mint szolgáltatók sem képesek teljesértékű funkcionális lefedettséget biztosítani a saját menetrendjük prezentálásakor. Mindez azért, mert nem áll kompetenciájukban az a számítás, melyet maga a menetrend tervező sem tud elképzelni, hogy létezhet. A dominó itt dől el. Jelentősen több adatra van szükség, hogy limitációk nélkül és könnyedén lehessen közlekedési menetrendeket illusztrálni a kedves utasoknak.