Modelowanie – SmarterPoland.pl

Na wojnie z koronawirusem najlepszą bronią jest informacja

To był dla mnie szalony rok, stąd brak aktywności na blogu fundacji SmarterPoland w ostatnich miesiącach. Jednak dzisiejszy artykuł na zdrowie.gazeta.pl sprowokował mnie do zabrania głosu nt. skandalicznej (nie)dostępności danych o rozwoju pandemii CoviD. O tym poniżej, ale jeżeli interesuje Cię tytułowy obrazek to więcej informacji o nim znajdziesz na końcu.

Ale po kolei.

Od kilku miesięcy współpracuję z zespołem MOCOS.pl, międzynarodową grupą badaczy zasilaną nieskończoną energią lidera – prof. Tylla Krugera z Politechniki Wrocławskiej. Jakiś czas temu zespół MOCOS przedstawił zbiór 10 rekomendacji w celu powstrzymania dalszego rozwoju epidemii. Poza punktami takimi jak testuj, ograniczaj kontakty, itp, znalazła się na tej liście rekomendacja szczególnie mi bliska, czyli ”Strategia cyfrowego zbierania i publicznego udostępniania danych”. Tytuł tego posta pochodzi właśnie z wspomnianej rekomendacji.

Dlaczego dostępność dobrej jakości danych jest taka ważna?

Brak dobrej jakości danych paraliżuje prace niezliczonej ilości podmiotów. Począwszy od modelarzy, którzy miesiącami opracowują modele predykcyjne dla możliwych scenariuszy pandemii, przez właścicieli małych biznesów, którzy nie wiedząc jak wygląda sytuacja nie mogą efektywnie planować swojej pracy, po szeregowych obywateli, którzy po prostu chcą wiedzieć co się dzieje. Bardzo chcą wiedzieć, więc jeżeli nie będzie oficjalnych rzetelnych danych to tworzy się przestrzeń dla fakenewsów.
Podstawowym wymogiem jest pomiary były porównywalne. W gwarze statystycznej mówi się o unikaniu porównywania jabłek do pomarańczy.
Tymczasem w przypadku danych covidowych raportowanych w Polsce zmieniają się sposoby liczenia podstawowych statystyk, takich jak liczba testów, liczba zakażonych (patrz np. tutaj). Przez to raportowane 10 zdiagnozowanych chorych liczonych we wrześniu liczonych jest w inny sposób niż 10 chorych w listopadzie. Podobnie z wykonanymi testami (chodzi o sposób w jaki wliczane są testy wykonane prywatne). Jeżeli w danych nie mamy informacji jak były liczone poszczególne współczynniki w kolejnych dniach, to dane są słabej jakości.

Równie ważna co jakość danych jest ich dostępność. Z niepojętego dla mnie powodu Ministerstwo Zdrowia jako główny kanał komunikacji o liczbie zakażeń wybrało Twittera. Aby robić jakiekolwiek powtarzalne analizy dane muszą być dostępne! Twitter to nie jest format przechowywania danych ani nawet nie jest dobre medium do udostępniania danych. Przed wakacjami dr. hab. Anna Ochab-Marcinek napisała parser przetwarzający twity Ministerstwa w bardziej dostępny format umieszczony na GitHubie. Ale albo sposób raportowania się zmienił, albo API Twittera się zmieniło i ten sposób pozyskiwania danych przestał działać.
Obecnie chyba wszyscy polscy modelarze korzystają z bazy danych ręcznie uzupełnianej przez Michała Rogalskiego (w wolnym czasie). Baza jest dostępna jako google spreadsheet. Cieszy mnie proaktywna postawa osób gotowych poświęcić dużo własnego czasu aby coś pożytecznego zrobić, ale spodziewałbym się, że w XXI wieku średniej wielkości państwo jest w stanie wystawić w kilka miesięcy oficjalne API z dostępem do kluczowych danych.

Pomijając już sam format danych. Całkowicie niezrozumiały jest dla mnie fakt, że Ministerstwo Zdrowia przestało publikować informacje o wieku, płci i chorobach towarzyszących zmarłych osób. Zasłaniając się tym, że zgonów jest tak dużo, że nie zmieściłyby się w twitach na Twitterze (tak jakby nie można było tych danych umieścić na stronach www MZ).

Równie ważna co jakość i dostępność danych jest też odpowiednia prezentacja danych. Od początku pandemii zbieram z różnych mediów sposoby prezentowania danych covidowych. Nigdy wcześniej nie widziałem takiego zainteresowania w mediach wykresami i statystykami. Niestety często przy okazji dobrych chęci wychodzi też na jaw kompletny brak umiejętności analizy i prezentacji danych w sposób czytelny. Dotyczy to zarówno gazet jak i oficjalnych rządowych komunikatów (widać nie jest czytelny, skoro wspomniane zdrowie.gazeta poświęciło cały artykuł na próbę zrozumienia jak czytać prezentowane statystyk śmiertelności).
Przykładowo, w danych jest ewidentny efekt dnia tygodnia wynikający z tego, że przez weekend wykonywanych jest mniej testów. Zanim zacznie się liczyć i pokazywać jakikolwiek trend, absolutnie podstawowym krokiem przetwarzania wstępnego jest uwzględnienie tego efektu. Niewiele jest jednak gazet, które to robią (jedyna, którą znam, pokazuje skumulowaną liczbę przypadków z ostatnich 7 dni, co jest jakąś formą radzenia sobie z tym problemem).

Gdybyśmy mieli dobrej jakości danych, moglibyśmy przygotowywać najróżniejsze raporty i statystyki (tutaj jest kilka statystyk opracowanych w grupie MOCOS).

Bez dobrych danych jesteśmy (społeczeństwo, modelarze, lekarze i też pewnie rząd) ślepi.

—

Wspomniane rekomendacje grupy MOCOS są dostępne tutaj: https://mocos.pl/pl/recommendations.html.

—

Korzystając z danych udostępnionych grupie MOCOS z okresu maj – wrzesień przygotowaliśmy kalkulator opisujący ryzyka zgonu lub hospitalizacji. Kalkulator ten jest dostępny na stronie https://crs19.pl/. Dane są dosyć stare, więc trudno powiedzieć na ile te relacje utrzymają się w listopadzie. Ten kalkulator to jedna z wielu rzeczy, które można by zrobić gdyby mieć dobrej jakości dane.

Projektowanie ekstremalne, czyli … z pamiętnika nauczyciela akademickiego

Dzisiaj będzie o pewnym ciekawym eksperymentalnym projekcie prowadzonym pomiędzy PW, UW oraz ASP. Przedmioty projektowe prowadzę od kilkunastu lat, ale ten był wyjątkowy. Poniżej krótko opiszę o co chodziło i jakie z tego zostały mi nauczki na przyszłość. Może komuś się przyda do realizacji podobnych zajęć.

Projekt dotyczył wizualizacji danych, a wizualizacja to bardzo interdyscyplinarny obszar. Pracując w takich miejscach można poznać bardzo ciekawe osoby z korzeniami w innych dziedzinach, od kontrolingu po wzornictwo przemysłowe. Tak się jakoś złożyło, że podczas poprzednich wakacji robiliśmy coś z dr Ewą Modrzejewską (Instytut Polonistyki Stosowanej, Uniwersytet Warszawski), której jedno z hobby to retoryka w wizualizacji danych. Mniej więcej w tym samym czasie pracowaliśmy nad Wykresami Unplugged z dr Magdą Małczyńską-Umeda (Akademia Sztuk Pięknych w Warszawie). Od słowa do słowa wykluł się w naszych głowach pomysł na zrobienie interdyscyplinarnego projektu, w którym na poważnie zderzylibyśmy perspektywę retoryczną, projektową i statystyczną.

Jak się bawić to na całego. A że w grupie raźniej to do zabawy zaprosiliśmy 20 studentów z zajęć, które prowadzimy. Kilku z dziennikarstwa UW, kilku z projektowania ASP i kilku z matematyki i informatyki MiNI PW.
Studentów podzieliliśmy na 4 grupy, w każdej grupie znaleźli się przedstawiciele każdej uczelni. Na warsztat wzięliśmy bardzo ciekawe dane otrzymane od firmy LekSeek. Dane dotyczyły częstości chorób w podziałach na wiek, płeć i inne cechy socjo-demo. Choroba to często dla młodych temat tabu. W projekcie chodziło o to by ten temat odczarować.

Każda z grup musiała znaleźć dla siebie jakiś temat a następnie przygotować analizy danych związane z wybranym tematem, krótki artykuł o wynikach analiz i plakat nawiązujący do analiz.
Wyszło naprawdę super. Poniżej jest jeden z plakatów, które zostały przygotowane. Tak, w tej głowie jest rozkład częstości wizyt lekarskich związanych z depresją w podziale na grupy wiekowe i płeć (autorem jest Dawid Grzelak, ASP). Genialne!

Więcej o samym projekcie, oraz o uzyskanych wynikach można przeczytać w raporcie Dane – Retoryka – Dizajn. W raporcie znaleźć można zarówno kody z analiz, jak i artykuły o wynikach i plakaty nawiązujące do znalezionych wyników.

After all myślę, że było to bardzo ciekawe doświadczenie i dla nas (prowadzących) i dla studentów. Zdecydowanie wychodzi się poza strefę komfortu.
Dla tych co chcieliby podobny projekt zrealizować, kilka doświadczeń:

– Logistyka w umawianiu spotkań dla studentów z 3 uczelni to oczywiście masakra. Nam się udało znaleźć jakieś popołudnia, ale czasem trzeba było w locie szukać innych terminów. Terminy spotkań lepiej zaplanować z wyprzedzeniem, najlepiej jeszcze przed rekrutacją studentów na taki projekt.
– Nasz projekt realizowany był podczas 3 wspólnych +- 2 godzinnych walnych spotkań, pomiędzy nimi był czas na prace w podgrupach. Lepiej byłoby mieć więcej dłuższych spotkań. Dwie godziny to mało aby przesiąknąć pomysłami osób z innych uczelni.
– Studenci z tak różnymi doświadczeniami mają różne sposoby pracy i potrzebują trochę czasu a czasem i pomocy by dograć się z resztą grupy. Jakieś małe zadania team-buildingowe powinny pomóc.
– Zestawienie przy jednym stole inżyniera informatyka, projektanta artystę i dziennikarza śledczego to ciekawa okazja by zobaczyć jak wygląda zupełnie inny warsztat pracy. Czasem jednak trzeba aktywnie zachęcać by poszczególne osoby chciały się tym warsztatem podzielić z nowymi współpracownikami.
– Tak różnorodne grupy to na początku spory chaos, ale z chaosu rodzą się fajne rzeczy.

Break Down: model explanations with interactions and DALEX in the BayArea

The breakDown package explains predictions from black-box models, such as random forest, xgboost, svm or neural networks (it works for lm and glm as well). As a result you gets decomposition of model prediction that can be attributed to particular variables.

The version 0.3 has a new function `break_down`. It identifies pairwise interactions of variables. So if the model is not additive, then instead of seeing effects of single variables you will see effects for interactions.
It’s easy to use this function. See an example below.
HR is an artificial dataset. The `break_down` function correctly identifies interaction between gender and age. Find more examples in the documentation.

#
# Create a model for classification
library("DALEX")
library("randomForest")
model <- randomForest(status ~ . , data = HR)

#
# Create a DALEX explainer
explainer_rf_fired <- explain(model,
                 data = HR,  y = HR$status == "fired",
                 predict_function = function(m,x) predict(m,x, type = "prob")[,1])

#
# Calculate variable attributions
new_observation <- HRTest[1,]
library("breakDown")
bd_rf <- break_down(explainer_rf_fired,
                 new_observation,
                 keep_distributions = TRUE)

bd_rf
#>                        contribution
#> (Intercept)                   0.386
#> * hours = 42                  0.231
#> * salary = 2                 -0.216
#> * age:gender = 58:male        0.397
#> * evaluation = 2             -0.019
#> final_prognosis               0.778
#> baseline:  0 

plot(bd_rf)

Figure below shows that a single prediction was decomposed into 4 parts. One of them is related to the interaction between age and gender.

BreakDown is a part of DALEXverse – collection of tools for visualisation, exploration and explanation of complex machine learning models.

Till the end of September I am visiting UC Davis and UC Berkeley. Happy to talk about DALEX explainers, XAI and related stuff.
So, if you want to talk about interpretability of complex ML models, just let me know.

Yes, it’s part of the DALEX invasion 😉
Thanks to the H2020 project RENOIR.

Ceteris Paribus Plots – a new DALEX companion

If you like magical incantations in Data Science, please welcome the Ceteris Paribus Plots. Otherwise feel free to call them What-If Plots.

Ceteris Paribus (latin for all else unchanged) Plots explain complex Machine Learning models around a single observation. They supplement tools like breakDown, Shapley values, LIME or LIVE. In addition to feature importance/feature attribution, now we can see how the model response changes along a specific variable, keeping all other variables unchanged.

How cancer-risk-scores change with age? How credit-scores change with salary? How insurance-costs change with age?

Well, use the ceterisParibus package to generate plots like the one below.
Here we have an explanation for a random forest model that predicts apartments prices. Presented profiles are prepared for a single observation marked with dashed lines (130m2 apartment on 3rd floor). From these profiles one can read how the model response is linked with particular variables.

Instead of original values on the OX scale one can plot qunatiles. This way one can put all variables in a single plot.

And once all variables are in the same scale, one can compare two or more models.

Yes, they are model agnostic and will work for any model!
Yes, they can be interactive (see plot_interactive function or examples below)!
And yes, you can use them with other DALEX explainers!
More examples with R code.

ML models: What they can’t learn?

What I love in conferences are the people, that come after your talk and say: It would be cool to add XYZ to your package/method/theorem.

After the eRum (great conference by the way) I was lucky to hear from Tal Galili: It would be cool to use DALEX for teaching, to show how different ML models are learning relations.

Cool idea. So let’s see what can and what cannot be learned by the most popular ML models. Here we will compare random forest against linear models against SVMs.
Find the full example here. We simulate variables from uniform U[0,1] distribution and calculate y from following equation

In all figures below we compare PDP model responses against the true relation between variable x and the target variable y (pink color). All these plots are created with DALEX package.

For x1 we can check how different models deal with a quadratic relation. The linear model fails without prior feature engineering, random forest is guessing the shape but the best fit if found by SVMs.

With sinus-like oscillations the story is different. SVMs are not that flexible while random forest is much closer.

Turns out that monotonic relations are not easy for these models. The random forest is close but event here we cannot guarantee the monotonicity.

The linear model is the best one when it comes to truly linear relation. But other models are not that far.

The abs(x) is not an easy case for neither model.

Find the R codes here.

Of course the behavior of all these models depend on number of observation, noise to signal ratio, correlation among variables and interactions.
Yet is may be educational to use PDP curves to see how different models are learning relations. What they can grasp easily and what they cannot.

ML nad Wisłą

28 maja odbędzie się pierwsze Warszawsko-Krakowskie Spotkanie Naukowe dotyczące uczenia maszynowego. Wspólne seminarium grup GUM (UJ) i MI2 (UW + PW) zajmujących się Machine Learningiem. Lista pięciu planowanych referatów jest tutaj (strona będzie uzupełniana). To pierwsze spotkanie, planowane są kolejne, na zmianę w Krakowie i Warszawie. Wstęp wolny. Będzie czas na poznanie się. Zapraszamy osoby zainteresowane poważniejszymi badaniami w obszarze ML.

W marcu odbyła się Gala Konkursu Data Science Masters na najlepszą pracę magisterską z obszaru Machine Learning i Data Science. Otrzymaliśmy w konkursie 72 prace z 17 uczelni! Zwycięzcy pierwszej edycji to: Tomasz Wąs (UW), Mateusz Susik (UW), Aleksander Nosarzewski (SGH). Wyróżnienia otrzymali: Dymitr Pietrow (WUT), Agnieszka Sitko (UW), Urszula Mołdysz (PŚ). Więcej informacji o nagrodzonych pracach na tej stronie (trochę trwało jej uzupełnienie). Dziękujemy Nethone (grupa DaftCode) za ufundowanie nagród.

Z okazji 100-lecia GUS w lipcu odbędzie się II Kongres Statystyki Polskiej. Więcej informacji na tej stronie. Jeszcze przez kilka dni można zgłaszać propozycje referatów. Jest kilka bardzo ciekawych sesji, np. poświęcona statystyce polskiej, analizie danych czy danym statystycznym.

Grupa europejskich badaczy ML apeluje do UE o utworzenie ELLIS: European Lab for Learning & Intelligent Systems, badawczego instytutu uczenia maszynowego na styku akademii i biznesu. Także w naszym kraju trwają prace nad powołaniem instytutu badawczego zajmującego się analizą danych. Robocza nazwa NISAD. Osoby zainteresowane tą inicjatywą zapraszam na priv.

Ministerstwo nauki ogłosiło konkurs na drugą edycję Doktoratów Wdrożeniowych. To może być ciekawa propozycja dla świeżych absolwentów pracujących w działach badawczych firm zainteresowanych zaawansowanym ML. Do tego programu można zgłaszać się jeszcze przez miesiąc.

DALEX: how would you explain this prediction?

Last week I wrote about single variable explainers implemented in the DALEX package. They are useful to plot relation between a model output and a single variable.

But sometimes we are more focused on a single model prediction. If our model predicts possible drug response for a patient, we really need to know which factors drive the model prediction for a particular patient. For linear models it is relatively easy as the structure of the model is additive. In 2017 we have developed breakDown package for lm/glm models.

But how to explain/decompose/approximate predictions for any black box model?
There are several approaches. The (probably) most known is LIME with great examples for image and text data. There is an R port lime developed by Thomas Pedersen. In collaboration with Mateusz Staniak we developed live package, similar approach, easy to use with models created by mlr package.
The other technique that can be used here are Shapley values which use attribution theory/game theory to attribute effects of different variables for a single prediction.

Recently we have developed a yet another approach (paper under preparation, implemented in the breakDown version 0.4) that works in a model agnostic way (here you can check how to use it for caret models). You can play with it via the single_prediction() function in the DALEX package.
Such decomposition is useful for many reasons mentioned in papers listed above (deeper understanding, validation, trust, etc).
And, what is really extra about the DALEX package, you can compare contributions of different models on the same scale.

Let’s train three models (glm / gradient boosting model and random forest model) to predict quality of wine. These models are very different in structure. In the figure below, for a single wine, we compare predictions calculated by these models. For this single wine, for all models the most influential variable is the alcohol concentration as the wine has much higher concentration than average. Then pH and sulphates take second and third positions in all three models. Looks like models have some agreement even if they structure is very different.

If you want to learn more about DALEX package and decompositions for model predictions please consult following cheatsheet or the DALEX website.

If you want to learn more about explainers in general, join our DALEX Invasion!
Find our DALEX workshops at SER (Warsaw, April 2018), ERUM (Budapest, May 2018), WhyR (Wroclaw, June 2018) or UseR (Brisbane, July 2018).

Explain! Explain! Explain!

Predictive modeling is fun. With random forest, xgboost, lightgbm and other elastic models…
Problems start when someone is asking how predictions are calculated.
Well, some black boxes are hard to explain.
And this is why we need good explainers.

In the June Aleksandra Paluszynska defended her master thesis Structure mining and knowledge extraction from random forest. Find the corresponding package randomForestExplainer and its vignette here.

In the September David Foster published a very interesting package xgboostExplainer. Try it to extract useful information from a xgboost model and create waterfall plots that explain variable contributions in predictions. Read more about this package here.

In the October Albert Cheng published lightgbmExplainer. Package with waterfall plots implemented for lightGBM models. Its usage is very similar to the xgboostExplainer package.

Waterfall plots that explain single predictions are great. They are useful also for linear models. So if you are working with lm() or glm() try the brand new breakDown package (hmm, maybe it should be named glmExplainer). It creates graphical explanations for predictions and has such a nice cheatsheet:

Install the package from https://pbiecek.github.io/breakDown/.

Thanks to RStudio for the cheatsheet’s template.

Co się działo na hakatonie Urban Sensors?

Hakaton Urban Sensors odbył się 26 września, dzień przed konferencją WhyR? Poniżej opiszę z jakimi danymi walczyliśmy i co ciekawego udało się zrobić.

Dane

Podczas tej jednodniowej imprezy pracowaliśmy z miejskimi danymi pochodzącymi z projektu VaVeL. Dokładniej z trzema źródłami danych:

Danymi online o położeniu autobusów i tramwajów w Warszawie. Poprzez interface REST pobieraliśmy szczegółową informację o tym gdzie znajdują się obecnie autobusy i tramwaje w Warszawie, ile są spóźnione, w którym kierunku jadą, kto je prowadzi, jaki jest najbliższy przystanek itp.
Danymi offline o położeniu autobusów i tramwajów. W plikach tekstowych mieliśmy zebrane informacje o położeniach autobusów i tramwajów przez cały lipiec i wrzesień. To całkiem spore dane. Logi dla jednego dnia zajmują średnio około 2.5GB.
Danymi offline z telefonii komórkowej. Dla poszczególnych stref Warszawy mieliśmy informacje ile było zdarzeń w sieci komórkowej w poszczególnych godzinach. Dane pokrywały lipiec i wrzesień. Te dane nie były tak duże jak informacje o ruchu pojazdów, ale były bardzo ciekawe.

Warsztaty

Hakaton rozpoczął się od dwóch krótkich warsztatów. Pierwszy prowadzony przez Przemysława Biecek opisywał jak dostać się do danych. Drugi prowadzony przez Ewę Baranowską poświęcony był interaktywnej wizualizacji z użyciem biblioteki D3. Materiały wideo z obu warsztatów będą dostępne na stronie hakatonu w połowie października.

Po warsztatach, uczestników hakatonu przywitali przedstawiciele partnerów projektu VaVeL. W kolejności wystąpienia, byli to: dziekan wydziału MiNI PW prof. Wojciech Domitrz; dyrektor Biura Cyfryzacji Miasta um. st. Warszawy, p. Tadeusz Osowski i dr Jarosław Legierski z Orange Labs.

Uczestnicy z entuzjazmem zabrali się do pracy z danymi. Intensywna praca trwała do godziny 20 i zakończyła się wieloma ciekawymi rozwiązaniami.
Zadanie nie było proste, dane były gigantyczne i nie wszystkie zespoły zdecydowały się na zaprezentowanie rozwiązań. Ale te zaprezentowane były bardzo ciekawe.

Wyniki

Prezentacje rozpoczął projekt Jana Bajerskiego, pokazujący jak wyglądają wizualizacje przejazdów autobusów i tramwajów na tle danych rozkładowych. Do wizualizacji wykorzystano diagramy Mareya. Z opracowanym narzędziem można się pobawić na stronie http://vis.tram.waw.pl (wersja rozwojowa).
Diagramy Mareya okazują się fantastycznym narzędziem by śledzić czy pojazdy się spóźniają, gdzie są wąskie gardła, jak bardzo się spóźniają, jak wydłuża się czas podróży. Można też łatwo zauważyć, czy autobusy tej samej linii mają tendencje do tworzenia ,,stad” kilku pojazdów jadących blisko siebie.

Kolejne rozwiązanie przedstawiła Ewa Baranowska. Pozwala ono w czasie rzeczywistym śledzić gdzie znajdują się obecnie autobusy i tramwaje w naszej okolicy. Interaktywna wizualizacja znajduje się na tej stronie.

Następnie Adam Wróbel przedstawił przeprowadzoną statystyczną analizę opóźnień tramwajów. Modelowanie z użyciem modeli regresyjnych pozwala szukać linii narażonych na wysokie ryzyko opóźnienia. Ciekawym wynikiem była ujemna korelacja przyrostów opóźnienia z przesuniętymi wartościami. Oznacza to, że (zgodnie z intuicją) motorniczy jeżeli ma opóźnienie i może je nadrobić to je nadrabia, a jeżeli jedzie przed rozkładem to zwalnia by zlikwidować nadczas.

Silny zespół z firmy Pearson w składzie Krzysztof Jędrzejewski, Mikołaj Olszewski, Mikołaj Bogucki, Mateusz Otmianowski, Kacper Łodzikowski przedstawił aplikację shiny, którą udało się błyskawicznie zbudować w czasie hakatonu. Aplikacja o wdzięcznej nazwie CzyZdążę.pl pozwala na sprawdzenie, dla planowanej trasy przejazdu, gdzie obecnie jest najbliższy tramwaj/autobus na który trzeba się spieszyć i ile średnio potrwa przejazd. To było niesamowite oglądać ile udało się temu zespołowi wykonać w ciągu zaledwie kilku godzin.

Pearson nie był jedyną firmą licznie reprezentowaną na hakatonie. Ciekawe rozwiązanie zaprezentował również zespół analityków z GfK Polonia w składzie Natalia Okińczyc, Barbara Czarnota, Andrzej Surma, Agnieszka Fronczyk. Przygotowali analizę przystanków skazanych na największe opóźnienia wraz z animowanymi wykresami wykonanymi w pakiecie animation.

Aplikacji skiny było więcej. Ciekawą analizę z użyciem biblioteki leaflet i shiny wykonał zespół z firmy Neuca (Karolina Mazanowska, Kamil Sieklucki). Ich wyniki znaleźć można na GitHubie.

Obok zespołów analityków z jednej firmy, w hakatonie brały udział zespoły w barwach wydziałowych. Silny zespół 100 składający się głównie ze studentów, doktorantów i absolwentów MIM UW zaprezentował ciekawą analizę danych dotyczącą dużych wydarzeń w mieście i ich wpływu na ruch miejski.
Ich wstępna analiza znajduje się pod tym adresem.

Wiele z opracowanych rozwiązań, razem z prezentacjami z warsztatów, można znaleźć w repozytorium GitHub.
Na zakończenie zorganizowaliśmy konkurs na najbardziej innowacyjne rozwiązanie.

Zwyciężył zespół z firmy Pearson, wyprzedzając o zaledwie kilka głosów rozwiązanie zaprezentowane przez Jana Bajerskiego. Zwycięska drużyna otrzymała na pamiątkę Pałac Kultury z nadrukowanym wielkim R.

Realizacja hakatonu była możliwa dzięki wsparciu ze strony organizatorów: Aleksandry Dąbrowskiej, Alicji Gosiewskiej, Klaudii Korniluk, Marcina Kosińskiego i Konrada Więcko; licznych ekspertów merytorycznych wspierających nas ze strony Urzędu Miasta Warszawa; przedstawicieli MiNI w osobie Grzegorza Bagrowskiego i Jarosława Legierskiego, którzy wiedzieli wszystko o danych; Krzysztof Wittelsa który wspierał nas organizacyjne ze strony Urzędu Miasta oraz całego zespołu projektu VaVeL, który przygotował infrastrukturę z którą mogliśmy pracować.

Hakaton już się zakończył, ale nie jest to ostatnia inicjatywa związana z analizą tych szalenie ciekawych danych. Wkrótce informacja o kolejnych.

Urban Sensors – hakuj dane o komunikacji w Warszawie

Urban Sensors to jednodniowy hakaton nad danymi miejskimi, który odbędzie się w Warszawie 26 września na wydziale MiNI Politechniki Warszawskiej (Koszykowa 75) – dzień przed konferencją WhyR.

Położenie online każdego tramwaju i autobusu

Kręcą Cię miejskie dane? Ten Hakaton to unikalna okazja pracy na dużych danych miejskich (więcej poniżej) wspólnie z pracownikami Urzędu Miasta Warszawa, którzy te dane znają od podszewki. Eksperci z urzędu miasta będą z nami przez czas trwania hakatonu, pomogą ocenić realizowalność nawet najbardziej szalonego pomysłu, zaproponują ciekawe tematy badawcze, wskażą gdzie szukać dodatkowych danych.

Hakaton prowadzony jest w ramach projektu VaVeL, dzięki któremu powstaje nowa unikatowa infrastruktura dostępu do bardzo głębokich danych online o tym co się dzieje w mieście. Podczas hakatonu będziemy pracowali na prototypowej platformie, z dostępem do danych których w takiej skali wcześniej nie było.

Dane z którymi będziemy pracować w pierwszej kolejności to położenie autobusów i tramwajów (GPS) oraz zagęszczenie osób w różnych rejonach Warszawy (na podstawie raportów ze stacji bazowych). Z danymi będzie można pracować w trybie online (online śledzenie gdzie jest teraz który autobus); trybie dostępu do danych historycznych (gigabajty danych o położeniu pojazdów z całego miesiąca); oraz trybie batch (zrzut danych dla dwóch wybranych ciekawych dni, względnie małe pliki).

Co będziemy robić na hakatonie?

Punktem wspólnym projektów na hakaton są dane miejskie, format rozwiązań może być dowolny. Przykładowe pomysły na projekty:
– tramRadar – aplikacja mobilna pokazująca gdzie w okolicy są w obecnej chwili tramwaje i jakie mają opóźnienie (jeżeli mają) na bazie danych online,
– automatycznie generowany dzienny raport z opóźnień w ruchu,
– system machine-learning przewidujący opóźnienie autobusów i tramwajów.
Można oczywiście też przyjść z własnym pomysłem.

Do samego hakatonu pozostało jeszcze trochę czasu. Jeżeli macie ciekawy pomysł na urozmaicenie tego wydarzenia, podzielcie się w komentarzach.

Podczas hakatonu nie planujemy bezpośrednich nagród finansowych.
Ale Urban Sensors to świetna okazja by popracować z danymi miejskimi nad projektem który może być wdrożony i skomercjalizowany, więc sława i pieniądze czekają na osoby, które na tej prototypowej platformie zbudują użyteczne usługi.

Jak się zapisać?

Zapisy na hakaton rozpoczną się 5 września.
Planujemy przyjąć 40-50 osób.
Pierwszeństwo będą miały osoby mogące pochwalić się ciekawymi realizacjami.
Informacja o zapisach pojawi się w pierwszej kolejności na stronie http://whyr.pl/hackathon/.