= Transport Analytics Datacube

== Explained 
По консултациите со асистентот, заедно размисливме и ни беше предложено дека најдобра напредна тема за проект од ваков тип е datacube аналитика, бидејќи системот за јавен транспорт природно генерира огромни количини на податоци кои бараат повеќедимензионална анализа. Уште од самиот почеток, системот беше замислен не само да ги чува податоците за возења, постојки и патници, туку и активно да детектира проблеми во мрежата како на пример: кои линии се преполни, кои постојано доцнат, и каде треба да се воведе нова линија или почест автобус. Аналитиката е организирана по линија, постојка, месец, час во денот и тип на ден (работен/викенд).
Поради ова, datacube пристапот се покажа како најсоодветна напредна тема, бидејќи со негова помош секоја линија, постојка и временски период автоматски добива статус и препорака директно во базата, без потреба од надворешна обработка. Наместо класични извештаи кои само прикажуваат историски податоци, системот е изграден околу принципот на активна детекција односно секој материјализиран поглед не само што групира податоци туку и носи конкретен заклучок директно во базата.

== New Materialized Views

[attachment:AdvancedMap.sql]

== New Materialized Views Explained
**1. {{{dim_time}}} - Временска димензија**
	•	Генерира по еден ред за секој час во еден период. За секој час чува година, месец, име на месец, квартал, час од денот, дали е работен ден или викенд и дел од денот(наутро, попладне, вечер). Служи како заедничка референтна табела за временско групирање низ целиот datacube.
**2. {{{fact_transport}}} - Факт табела за патувања**
	•	 Секој ред во оваа табела е едно конкретно, реално патување што се случило, на пример "Автобус бр.17, на 15 јануари во 8:15 наутро, имал 23 патници, заработил 460 денари, доцнел 4 минути, бил 65% полн." Ако базата има 50.000 патувања, табелата има 50.000 редови — без групирање, без просеци меѓу патувања, чисто сирови податоци по патување. Ова е изворната табела од која се останато се пресметува.
**3. {{{mv_transport_cube}}} - Главен datacube за анализа**
	•	 Оваа табела не гледа поединечни патувања туку групи патувања, секој ред претставува сума/просек за одредена комбинација од категории (рута, месец, година, час, тип ден, time slot, статус), наместо едно патување. Ова се прави за сите можни комбинации од тие 7 категории, вклучувајќи и комбинации каде некои категории се празни.
**4. {{{mv_schedule_mismatch}}} - Детекција на доцнење по линија и час**
	•	 Со постепено собирање по рута, час и тип ден (прво по час, па вкупно по рута, па целосно вкупно) ги собира бројот на патувања, просечно и максимално доцнење, бројот и процентот на доцните патувања и доделува текстуален статус (критично, проблематично, умерено, ок) во зависност од просечното доцнење.
**5. {{{mv_overcrowding_analysis}}} - Детекција на преполни линии**
	•	 Групирано по рута, месец, час, тип ден и временски период, ги пресметува просечната пополнетост и најпополнетиот момент, бројот на патувања, колку биле преполни и колку над капацитет и генерира препорака (итно, препорачано, следи, ок) за тоа колку треба да се зголеми фреквенцијата.
**6. {{{mv_stop_demand}}} - Побарувачка по постојка**
	•	 За секоја постојка, групирана по месец, час и тип на ден, се брои бројот на патувања што минуваат низ неа, бројот на качувања и просечниот број патници. Врз основа на споредбата меѓу бројот на патувања и бројот на качувања, се доделува статус дали е потребна нова линија, заради поголема фреквенција, или се е во ред.
**7. {{{mv_ride_shift_detection}}} - Детекција на преминување кон друга линија**
	•	 За патувања што доцнат повеќе од 10 минути, го споредува реалниот број патници со просечниот број патници на истата рута и час кога нема доцнење, и пресметува процент на пад на патници. Ако падот е поголем од 20%, го означува статусот како веројатен ride shift (патниците преминале на друга линија/превоз).
**8. {{{mv_optimization_recommendations}}} - Финален предлог за оптимизација**
	•	 Ги комбинира **{{{mv_overcrowding_analysis}}}** и **{{{mv_schedule_mismatch}}}** за секоја комбинација рута/час/тип на ден, и генерира една крајна препорака: целосна ревизија ако линијата е и преполна и доцни, зголемување на фреквенцијата ако е само преполна, корекција на распоредот ако само доцни, или без итни препораки. 

== Map 

Целата мапа е направена со Leaflet.js и се прикажува врз темна подлога, центрирана на центарот на Melbourne. Горе има копчиња со секој слој посебно, за Stops, Routes, Buses, Trains, Trams. Кога слојот Stops е вклучен, се гледаат точки на мапата за секоја станица, обоени според статусот, зелено значи дека станицата е ОК, жолто значи дека и треба поголема фреквенција, а црвено значи дека и треба сосема нова линија. Кога слојот Routes е вклучен, се цртаат самите транспортни линии како обоени патеки по мапата, со иста логика на бои според тоа колку линијата е проблематична. Buses / Trains / Trams слоевите се икони кои реално се движат по трасите во реално време, симулирајќи возила во сообраќај.
Лево има панел со целосна листа на сите линии, со поле за пребарување по име. Листата автоматски е сортирана така што најпроблематичните (црвените) линии стојат на врв, а на самиот врв на панелот има три броеви кои покажуваат вкупно колку линии се црвени, жолти и зелени во моментов. 
Кога ќе се кликне на линијата, или на листата лево или директно на мапата, таа линија се истакнува, сите други линии привремено се затемнуваат, станиците и возилата се гасат, и мапата автоматски се зумира да ја опфати целата избрана линија. Тогаш десно се отвора панел со детали, растојание на линијата, проценето време на патување, пополнетост и delay, и конечната препорака.

Станиците земени од **{{{/api/stops}}}** се реални односно имињата, координатите и типот на возило доаѓаат директно од табелата stops, а статусот на секоја станица реално се пресметува од **{{{my_stop_demand}}}**. Геометријата на линиите на мапата исто е реална, од shape_point, само прикажува случаен избор од 300 shapes заради перформанс, но самите координати се точни. Имињата на линиите и бројот на trip-ови по линија се исто реални, извлечени преку join помеѓу trip и route.
Со новите materialized views што ги имаме, рандом деловите можат директно да се заменат со реални податоци. Препораката за секоја линија би дошла од **{{{my_optimization_recomendations}}}**, која веќе го спојува overcrowding статусот со delay статусот по route_name/час/тип на ден и дава готово поле final_recommendation со истите категории. Полето avg_occupancy би дошло директно од **{{{mv_overcrowding_analysis}}}**, а avg_delay од **{{{mv_schedule_mismatch}}}**, двете веќе пресметани per route, per hour, per day_type. **{{{mv_transport_cube}}}** дополнително нуди веднаш достапни агрегати како вкупен број патници, приход и процент преполни trips по линија, кои моментално воопшто не се прикажуваат. Единствено движењето на возилата не може директно да се извлече од овие views, за тоа би требало да се пресметува во кој момент, помеѓу кои две последователни stop_time записи, се наоѓа секој активен trip, и позицијата да се вметни по shape_point координатите на таа патека.