Pri cteni vsech tech navrhu a zmen linkoveho vedeni tuhle a taamhle, luxusnich a natriskanych useku a magistratnich hratek me napada jedna vec:
Predstavme si virtualni system.
1. Do systemu zadam data o prazske tramvajove siti, obsahujici informace typu odkud se da kam dojet, kde je ktera zastavka, kde je ktera smycka, vozovna, jake jsou v ktere krizovatce oblouky, jake jsou mezi jednotlivymi prvky (krizovatky, zastavky, smycky, vozovny... atd.) vzdalenosti a pripadne jeste treba dalsi parametry tykajici se propustnosti trati (napriklad pocet a technicke parametry SSZ, technicky stav koleji a rozmisteni vsech predstavitelnych omezeni) a moznosti prestupu v jednotlivych zastavkach.
2. Do virtualni mapy tramvajove site doplnim na zaklade nejake fundovane analyzy (nevim jestli probehla, jestli ne tak by bylo vice nez vhodne ji provest) intenzity prepravni poptavky mezi libovolnymi dvema zastavkami, v zavislosti na tom zda jde o ranni nebo odpoledni spicku, sedlo, noc nebo vikend.
3. Doplnim dale jeste informace o jednotlivych vozech, jejich mnozstvi ve vozovnach a jejich parametrech (max. obsaditelnost, prujezdnost, spotreba).
Nyni systemu s temito informacemi polozim nasledujici ukol: Vytvor plan linkoveho vedeni takovy, ktery maximalizuje uspokojeni prepravni poptavky, minimalizuje provozni naklady a zaroven obsluhuje vsechny zastavky v siti s minimalizovanym poctem prestupu.
Predpokladam ze po zpracovani ukolu by mi system predlozil neco jako "minimalni" linkove vedeni, tj. vedeni ktere obsluhuje vsechny zastavky pouze nezbytne nutnym poctem spoju, schopnym odvezt prislusnou prepravni poptavku v danem smeru, s minimalnim nutnym poctem prestupu a s minimalnimi naklady. Dale bych ocekaval vytvoreni navrhu grafikonu pro jednotliva obdobi, planu pro obsazeni jednotlivych linek jednotlivymi druhy vozu a navrh ucasti jednotlivych vozoven na provozu a pripadne jeste trasy vyjezdu a zatahu na jednotlive linky pro jednotlive vozovny.
Myslim si, ze takovy system je jiste realizovatelny a urcite by pomohl vyresit spory tykajici se linkoveho vedeni. V pripade magistratich hratek typu "musi byt spojeni z A do B at se deje co se deje" mohu tento pozadavek systemu predlozit jako nemenitelny a nechat ho vyresit ulohu s nim. Pokud by se pri vyvoji systemu ukazaly dalsi parametry, ktere je treba systemu predlozit a ktere maji vliv na vysledny vypocet, neni nic jednodussiho nez parametry doplnit a vypocet tak optimalizovat. Od urciteho poctu parametru ale nepredpokladam ze by dochazelo ke zmenam ve vysledku, preci jen - mnozina vsech moznych linkovych vedeni po Praze je celkem mala, jakkoliv se nam muze zdat nekonecna, nekonecna neni... Vysledny stav by mel uspokojit naprostou vetsinu pozadavku a to jak ze strany provozovatele tak ze strany cestujicich. Jedine co by bylo asi vnimano jako problem, ze by "nezustal kamen na kameni" respektive ze zadna z linek by nezustala (resp. nemusela by zustat, pokud by se neprojevila genialita tvurcu linkoveho vedeni) ve sve puvodni podobe a na to by bylo treba si zvyknout. Ale - ruku na srdce - zvyknout se da na vsechno. Byla-li by vule ze strany provozovatele, stacilo by nastavenim jedineho parametru, tj. nakladu na provoz, zmenit vysledek tak, abychom za dane finance ziskali maximalne dobre fungujici dopravu.
Vse je jen otazka aplikaci algoritmu linearniho programovani, softwarove zpracovani a zadani vsech dostupnych informaci. Az nekdy v daleke budoucnosti nebudu mit co programovat tak bych rad neco podobneho zkusil nakodit.
