Taksówką po Nowym Jorku – konkurs Kaggle.com

Jest sobie taka strona – Kaggle.com – na której badacze danych mogą próbować swoich sił w różnych konkursach. Najczęściej chodzi o to, żeby z opublikowanych danych treningowych przewidzieć wyniki dla danych testowych.

Tak jest w przypadku konkursu NYC Taxi Trip Durration w którym uczestniczę. Chodzi pokrótce o to, żeby na podstawie informacji o kursach taksówek przewidzieć czas trwania podróży. Do dyspozycji mamy dane z pierwszego półrocza 2016 roku – prawie półtora miliona wierszy. Jeśli chcesz spróbować swoich sił albo po prostu sprawdzić opublikowany niżej kod – ściągnij dane ze strony konkursu (do tego wpisu wystarczy plik train.csv).

W tym poście nie pokażę rozwiązania i nie zbuduję modelu (można kilka zobaczyć na stronie konkursu, moje też), ale przejdziemy przez cały proces analizy danych, odpowiedniego ich czyszczenia (w nieco skróconej formie) i szukania ukrytych w nich informacji. Wpis raczej mało popularnonaukowy, ale może interesuje Cię gdzie nowojorczycy jeżdżą taksówkami?

Potrzebujemy tylko kilku pakietów, z czego większość dla jednej czy dwóch funkcji.

Plik z danymi wrzucamy do folderu data/, a później wczytujemy:

Co my tutaj mamy?

Kolejne cechy to:

  • id – ID konkretnego kursu
  • vendor_id – ID korporacji taksówkarskiej (są dwie)
  • pickup_datetime – data i czas rozpoczęcia kursu
  • dropoff_datetime – data i czas zakończenia kursu (oczywiście nie ma tego pola w danych testowych)
  • passenger_count – liczba pasażerów
  • pickup_longitude oraz pickup_latitude – lokalizacja (współrzędne geograficzne) miejsca rozpoczęcia kursu
  • dropoff_longitude oraz dropoff_latitude – miejsce zakończenia kursu. W realnym świecie ta informacja może nie być dostępna w momencie rozpoczęcia kursu – jednak na potrzeby konkursu pozostawiono ją w danych. Ciekawe było by przygotowanie modelu bez tej informacji…
  • store_and_fwd_flag – flaga mówiąca o tym czy dane o kursie były przechowywane w pamięci pojazdu przed wysłaniem do sieci taksówkarskiej kiedy pojazd nie miał połączenia z serwerem; w niniejszym wpisie odpuścimy sobie analizę tego pola
  • trip_duration – czas trwania podróży (w sekundach). To coś co należy znaleźć dla danych testowych

Na początek pozbędziemy się wszystkich danych odstających.

Zaczniemy od lokalizacji. Czy miejsca są w miarę zwarte czy też mocno rozproszone? Narysujemy histogramy dla każdej ze współrzędnych i sprawdzimy. Wszystkie miejsca powinny być skupione w jakimś ograniczonym terenie.

Sprawdźmy szerokość geograficzną miejsc startowych kursu (weźmy tylko 10% danych, żeby narysowało się to szybciej):

A teraz długość geograficzną tych miejsc:

Jest tak jak zakładaliśmy, z małymi wyjątkami (osie poziome na obu wykresach byłyby krótsze, gdyby nie odstające punkty). Widać to zresztą po podsumowaniach odpowiednich kolumn:

Dla szerokości mamy środek w punkcie 40.75 i pojedyncze punkty o około 10 stopni kątowych na północ i na południe (1 stopień szerokości to – jak wiemy z geografii i geometrii – 20 tys. km dla 180 stopni = 111.1 km), czyli o jakieś tysiąc kilometrów od środka! To na pewno błędy. Dla długości geograficznej mamy jeszcze większe różnice.

Metodą przybliżeń (odpowiedniego filtrowana z jednej i drugiej strony) histogramu uzyskałem granice obszaru NYC:

  • dla szerokości – od 40.6 stopnia do 40.9 stopnia
  • dla długości – od 74.25 stopnia do 73.75 stopnia (na półkuli zachodniej, stąd minusy)

Mamy 1458644 wierszy wszystkich danych. Po przefiltrowaniu (w tych samych granicach miejsce rozpoczęcia i zakończenia kursu):

zostaje nam 1454759 wierszy. Nie straciliśmy wiele (jakieś 4 tysiące, jak dobrze liczę? to jest około 0.25% danych). Zobaczmy jak teraz wygląda rozkład. Żeby było inaczej – tym razem dla zakończeń kursu (też na 10% danych, tym razem z 10-krotnie większą dokładnością)

  • szerokość geograficzna:

  • i długość geograficzna:

Dużo lepiej, prawda? Co to są te najpopularniejsze miejsca, wiecie? Skąd odjeżdżają taksówki? Zobaczmy na mapie: (znowu – 10% danych)

A dokąd przyjeżdżają?

To jest moment w którym słyszysz Błękitną rapsodię i widzisz początek jednego z moich ulubionych filmów Woody Allena. Tego nie można nie znać… niecałe 4 minuty, możesz poświęcić na obejrzenie:

Manhattan. Po prostu . Tam jest największy ruch. Widać wyraźnie pusty prostokąt Central Parku. Widać też skupisko w prawym dolnym rogu. Dojdziemy z czasem do tego czym ono jest (nie znam Nowego Jorku, więc nie rozpoznaję. Rozpoznaję Kraków i Warszawę :).

Czas na drugie filtrowanie. Sprawdźmy najpierw jak wygląda rozkład czasu podróży:

Widać, że są jakieś minimalne (mniej niż 30 sekund w taksówce to dość dziwaczne, podobnie więcej niż – powiedzmy – dwie godziny (7200 sekund)). Obetnijmy właśnie tak dane.

Z 1454759 wierszy…

zostaje nam 1447865 – znowu usunęliśmy niewiele (jakieś 0.5%). Wszystko po to, żeby wartości odstające nie wpływały na model.

Teraz rozkład czasu podróży wygląda tak:

Można było obciąć przy 6000 sekundach, nawet może i 5000?

Na razie mamy tylko odrzucone wartości dziwne – poza miastem i podróże zbyt długie (oraz zbyt krótkie). Niczego nie wiemy o charakterze zmian czasu podróży – czy od czegoś zależy? A przecież to czas podróży mamy prognozować!

Najpierw przygotujmy informacje o dacie, tak aby pozwalały na różne przekroje. Nie mamy w danych testowych informacji o momencie zakończeniu kursu, więc odpuścimy sobie ją w danych treningowych. Zresztą data i godzina zakończenia kursu będzie prawie jednakowa z porą jego rozpoczęcia. To chyba niewiele wniesie do modelu.

Czy liczba kursów zależy od miesiąca?

No nie bardzo, a gdyby jeszcze przeskalować ją ilością dni w miesiącu to już pewnie wcale.

A od dnia tygodnia? Najpierw zmienimy numerację dni tygodnia. Pakiet lubridate uznaje niedzielę za początek tygodnia (dzień numer 1) i sobotę (dzień numer 7) za koniec. Musimy to “zrolować” nieco:

Teraz pierwszy dzień tygodnia to poniedziałek. Więc jak wygląda rozkład ilości kursów w poszczególne dni?

Szczerze mówiąc minimum poniedziałkowe nieco dziwi… Pytanie ile było poniedziałków? Może lepiej liczyć średnią? Sprawdźcie.

Zobaczmy rozkład po godzinach:

To już wygląda sensownie – minimum nad ranem, w miarę umiarkowanie w ciągu dnia i szczyt popołudniowy (po pracy, po wieczornych rozrywkach). Czy to się zmienia w ciągu tygodnia?

Widać górkę popołudnowo-wieczorną przesuniętą na później w weekend, a także więcej podróży w weekend w okolicach północy. Ładnie to widać też na innego rodzaju wykresie:

na którym widać też większą liczbę przejazdów w okolicach 8 rano.

Zobaczmy jeszcze układ dzień po dniu (bo jest ciekawy):

Coś zwróciło Waszą uwagę? Jest cyklicznie, co siedem dni. Ale w dniach 23 i 24 stycznia 2016 roku stało się coś dziwnego. Jak odrzucimy te dni mamy:

…o wiele bardziej widoczną tygodniową cykliczność. Jakby to było wykres typu calendar plot to byłoby jeszcze ładniej.

Ale wróćmy do tego 23-24 stycznia. Trzeba googlać. Albo pamiętać. Tej nocy nad Nowym Jorkiem przeszła ogromna śnieżyca (ogromna w wersji amerykańskiej – więcej krzyku niż prawdziwej zimy). Służby zapowiadały kataklizm, chyba wstrzymany był ruch na ulicach. Googlajcie po szczegóły.

Możemy sprawdzić jak długo (tym razem czas w minutach) trwa podróż taksówką w zależności od dnia tygodnia i pory dnia:

W ciągu dnia roboczego podróże są stosunkowo krótkie – około 15-16 minut. Najkrótsze są przejazdy weekendowe.

Wiemy coś o czasie, mamy położenia początku i końca – możemy zatem policzyć odległości pomiędzy punktami. Mając czas i odległość możemy policzyć prędkość. Do dzieła zatem.

Najpierw odległości (po sferze – używając distHaversine(), można w sumie liczyć zwykłą odległość euklidesową – w ramach miasta krzywizna Ziemi nie będzie mieć dużego znaczenia), a przy okazji kierunek (azymut – korzystając z funkcji bearing()). Obie funkcje pochodzą z pakietu geosphere. Ten kawałek kodu wykonuje się długo; przeliczone dane warto więc zapisać i później z nich korzystać żeby nie liczyć wielokrotnie.

Zobaczmy jak wygląda rozkład długości podróży:

Widzimy górki w okolicach 9-10 kilometrów oraz nieco powyżej 20. Wszystko się wyjaśni :)

A jak wygląda rozkład azymutów?

Widzimy dwa piki:

Zobaczmy jakim podróżom to odpowiada:

Tam i z powrotem po Manhattanie. Zauważyliście oczywiście, że -151 i 29 to idealnie przeciwne kierunki (suma wartości bezwzględnych to 180). Wystarczyło też użyć przekształcenia układu współrzędnych na wykresie z rozkładem, o tak:

Policzmy teraz wspominaną już prędkość dla każdej z podróży. Odległości mamy w kilometrach, a czas w sekundach – stąd stosowny mnożnik.

Widać, że bez większej utraty informacji możemy wyciąć te kursy, których prędkość przekracza 90 km/h (można nawet i 75 km/h). Owo 90 wziąłem z przybliżeń, podobnie jak z długością i szerokością geograficzną. Można również obcinać po percentylach albo krotności odchyleń standardowych od średniej (w przypadku rozkładów normalnych).

Możemy teraz przeprowadzić analizę prędkości przejazdu w poszczególnych godzinach lub dniach tygodnia – analogicznie jak robiliśmy to dla ilości przejazdów. Zapewniam, że widać godziny szczytu (i związane z nimi korki). Wystarczy heatmapa:

Jak widać jest analogicznie, z tym że odwrotnie (im więcej przejazdów tym mniejsza średnia prędkość).

Lotniska. To ważne miejsca dla taksówek. I już się pojawiły – pamiętacie prawy dolny róg mapki? Pamiętacie kursy długości około 10 i około 20 kilometrów. To właśnie lotniska. W Nowym Jorku są dwa (La Guardia i JFK), z Wikipedii weźmiemy ich współrzędne i oznaczymy odpowiednio punkty rozpoczęcia i zakończenia kursów. Z dokładnością do 2 setnych stopnia, czyli około 2.2 kilometrów. Powinno wystarczyć.

Zobaczmy jak dużo wszystkich kursów związanych jest z danym lotniskiem:

3.7% kursów to z/na JFK, 2.7% kursów związanych jest z La Guadrią. To odpowiada wysokości słupków na histogramie długości (w sensie odległości) kursów Chcesz to sprawdź, które lotnisko jest przy 10 km, a które przy 20 km. Albo zobacz na mapę ;)

Ciekawostka – 0.1% przejazdów (czyli 742 w pół roku – 4 dziennie, o ile mamy dane o wszystkich kursach) to kursy pomiędzy lotniskami.

Czy czas przejazdu wiąże się z przejazdem do/z lotniska?

Dla lotniska JFK:

Dla La Guardia:

Widać, że kursy do/z lotniskiem mają inną średnią niż cała reszta. To dość oczywiste i już to wiemy ze wcześniejszych wykresów. Większość kursów odbywa się po Manhattanie, lotniska są poza nim w dodaku w różnej odległości. Musi to wpływać na czas przejazdu.

Średni czas podróży w zależności od tego czy kurs dotyczył lotniska (i którego):

Znowu mamy dowód, że JFK jest dalej. Czasy chyba podobne do warszawskich (ze Śródmieścia na Okęcie jedzie si ę z 30-45 minut, prawda?).

Teraz spróbujemy czegoś nowego – podzielimy miejsca rozpoczęcia i zakończenia kursów na grupy (klasy). Skorzystamy z algorytmu k-średnich. Przyjmijmy powiedzmy 50 grup. Liczba grup może być istotna dla późniejszego modelu – trzeba eksperymentować.

Jedna uwaga, dość istotna. Tutaj dzielę osobno miejsca rozpoczęcia kursu i jego zakończenia. To oznacza, że:

  • grupy mogą nie być identyczne (mogą mieć inny kształt i liczność)
  • ten sam punkt może wpaść do grupy A w przypadku rozpoczęcia w nim kursu, a do grupy B w przypadku zakończenia

Wynika to z charakteru algorytmu k-średnich. Poprawnym rozwiązaniem byłoby zebranie wszystkich punktów (pickup i dropoff) do jednej tabeli, a co więcej – razem z tymi samymi współrzędnymi dla danych testowych i podział tej tabeli na grupy. Później (na podstawie współrzędnych) trzeba odpowiednio przepisać dane o przynależności do grupy z powrotem do danych o kursach.

Dla uproszczenia przygotujemy grupy osobno:

Jak wygląda przypisanie punktów początkowych do grup (czyli: które miejsca miasta są w których grupach)? Zobaczmy na mapie:

Jest zgodnie z tym czego można było się spodziewać: tam gdzie jest dużo kursów obszary danej grupy są mniejsze. Bardzo ładnie wydzieliło się lotnisko JFK w prawym dolnym rogu, La Guardia wygląda jakby należała do dwóch albo trzech grup? Możemy to sprawdzić:

Z danymi o lokalizacji możemy zrobić jeszcze jedną rzecz – przekształcić je za pomocą PCA. Wiele to nie zmieni (z 2D przekształcamy w 2D), ale obrót płaszczyczny i skalowanie współrzędnych może pomóc modelom.

Jaki to daje wynik? W połączeniu z grupowaniem:

Jak widać całość się obróciła. Nie udało się znaleźć żadnych ukrytych właściwości.

To już wszystkie cechy, które dodaliśmy. Początkowo było ich 11, na koniec mamy 30:

Niektóre z cech są silnie skorelowane ze sobą – można je wyeliminować (niewiele wniosą do modelu). Na pewno trzeba zapisać przygotowane dane, żeby nie powtarzać za każdym razem tego samego procesu – jest w końcu dość pracochłonny (liczenie odległości, klasyfikacja punktów do grup). Lepiej czas (komputera, bo przecież mamy już maszynę) poświęcić na przygotowanie modelu.

Ja przejrzałem dla Was dane. Zrobicie dla mnie model?

Wszystkie powyższe operacje należy wykonać również na danych testowych, tak aby modele mogły czerpać z tego samego zestawu cech. Oczywiście nie policzymy prędkości.

Warto sięgnąć również do innych źródeł (konkurs tego nie zabrania) – chociażby godzinowych danych o pogodzie. Czy padał deszcz albo śnieg? Jeśli tak – prędkość spada. Być może pojawią się jakieś ukryte zależności. Jeśli udałoby się uzyskać dane o natężeniu ruchu – też mogą być ciekawe i pomocne. Może warto oznaczyć dni wolne od pracy?

Pominęliśmy całkowicie informacje o liczbie pasażerów i korporacji taksówkowej – warto prześledzić czy te informacje mają wpływ na czas przejazdu. To kilka prostych wykresów, przygotujcie je samodzielnie.

Polecam również zapoznać się z analogicznymi analizami publikowanymi już na Kaggle w ramach konkursów, chociażby bardzo dobrym NYC Taxi Rides EDA. Uzbrojeni w wiedzę o zależnościach pomiędzy zmiennymi i możliwościami wyciągnięcia ukrytych informacji nie musimy poświęcać czasu na samodzielną analizę. Możemy skupić się na przygotowaniu modelu.

Dodaj komentarz