Wykorzystanie zewnętrznego i gotowego narzędzia do wyszukiwania przejazdów jest zwykle tańszym i mniej skomplikowanym rozwiązaniem niż próba stworzenia własnego. Często spółki transportowe stawiają na własne, autorskie aplikacje – zarówno webowe jak i mobilne – dzięki którym ich pasażerowie są w stanie wyszukiwać optymalne połączenia bazujące na danej siatce połączeń. Wydaje się to sensownie, nieprawdaż?
Zdecydujmy postawić się w sytuacji turysty – skąd taka osoba, zwykle posługująca się na co dzień innym językiem niż ten, który jest powszechnie używany w odwiedzanym kraju – ma wiedzieć, że w celu znalezienia połączenia z punktu A do punktu B należy zaopatrzyć się w specjalną apkę (zwykle dostępną tylko języku autochtonów). Jak sprawić, że taka osoba w ogóle będzie chciała (i widziała o jej istnieniu!) skorzystać z komunikacji publicznej?
Fot. Daria Nepriakhina / Unsplash.
Z drugiej strony – wystarczy przypomnieć sobie, kiedy ostatni raz byliśmy zmuszeni do oddania auta do mechanika i powrotu do domu w inny sposób. Jeżeli przyzwyczajeni jesteśmy do poruszania się transportem indywidualnym, to zwykle nawet nie jesteśmy świadomi przebiegu danych linii autobusowych albo tramwajowych.
Innym aspektem jest także równanie do powoli kształtujących się standardów – obecnie możliwe jest wyznaczenie optymalnego połączenia dla tak, może dosyć kuriozalnego (ponad 29 godzin podróży obejmującej 10 przesiadek) z Rzymu do Dublina.
Dlaczego więc nie równać do najlepszych i ułatwić życie mieszkańcom oraz turystom?
W następnych częściach artykułu będę posługiwał się uproszczeniami. Jako klienta będę rozumiał Urząd Miasta i Gminy w Wieliczce, a jako konsultanta – moją rolę w tym procesie. Z kolei za narzędzie lub usługę będę rozumiał Transport publiczny na Mapach Google (ang. Google Transit).
Fazy implementacji
Jak wiadomo, każdy proces składa się z kilku(nastu) etapów, w zależności od jego skomplikowania. Zostały podzielone na trzy większe fazy – przed, w trakcie, oraz po wdrożeniu.
W spisie nie uwzględniłem samego procesu komunikacji z klientem, a sam proces rozpoczyna się już w momencie nawiązania kontaktu i wyrażenia chęci (i zgody) do przeprowadzenia implementacji. W zależności od tego, jakiego rodzaju jest to klient – czy jest to małe lokalne przedsiębiorstwo dysponujące kilkunastoma busami, czy też duża firma o ponadregionalnej siatce połączeń, czy też wydzielona jednostka miejska lub gminna, do której kompetencji należy organizacja transportu publicznego – do każdego z rodzaju klienta należy podejść w zgoła inny sposób, przedstawiając wady, zalety, a także – co chyba najważniejsze – przebieg procesu implementacji.
Faza przedwdrożeniowa
- Przygotowanie pliku danych zgodnie ze specyfikacją General Transit Feed Specification (GTFS).
- Konfiguracja konta Transit Partnerdash.
Faza wdrożenia
- Opublikowanie pliku danych w celu przetworzenia przez serwery Google.
- Badanie usability z pomocą użytkowników testowych oraz wykorzystując narzędzia udostarczone w Google Transit Partnerdash.
- Sprawdzenie poprawności danych wraz z zespołem Google, aby zapewnić wysoką jakość i dokładność danych.
- Uruchomienie integracji w usłudze Transport publiczny na Mapach Google.
Faza podwrożeniowa
- Walidacja wdrożenia, ciągłe monitorowanie feedbacku oraz statystyk.
- Planowanie rozwoju.
Implementacja
Tuż po nawiązaniu kontaktu z klientem i ustaleniu warunków współpracy w ramach projektu prace zostały rozdzielone na dwa etapy. Równocześnie, wraz z przygotowywaniem zestawu plików w formacie GTFS rozpoczęta została procedura requestowania dostępu do panelu Google Transit jako nowej organizacji zainteresowanej uczestnictwem. Co ważne, takie uczestnictwo jest w pełni bezpłatne dla każdego zainteresowanego podmiotu, przez co koszty, jakie ponosi klient to utrzymanie infrastruktury, przystosowanie feedu GTFS oraz ewentualna pomoc zewnętrznych konsultantów w przypadku braku wewnętrznego zaplecza.
Podstawą sukcesu na tym etapie było dostarczenie rozkładów jazdy od razu w postaci skoroszytu, przez co czas procesu został skrócony o czas, który musiałby zostać poświęcony na ręczne przepisywanie danych lub stworzenie programu przetwarzającego rozkłady, w formacie tekstowym, umieszczone na stronie internetowej, lub, co gorsza, jedynie w postaci obrazków osadzonych na stronie przewoźnika.
Sam proces uzyskiwania dostępu do panelu przebiegł sprawnie, dzięki niesamowitemu uproszczeniu procedury po stronie dostawcy i jego ograniczeniu do kilkukrotnej wymiany wiadomości wraz z akceptacją odpowiednich umów na świadczenie usług w ramach Google Transit.
Pod odpowiednim przygotowaniu plików i uzyskaniu dostępu do panelu (oraz uprzedniej walidacji za pomocą narzędzi), pliki zostały przekazane do narzędzia, gdzie zostały poddane wstępnemu przetworzeniu.
Kolejnym krokiem było badanie przygotowanego feedu przez użytkowników testów, którym zostały udzielone dostępy do podglądu działania feedu. Obejmowały one przede wszystkim sprawdzenie pod kątem umieszczenia we właściwych miejscach przystanków oraz walidacji, czy proponowane połączenia oraz przesiadki są sensowne, to znaczy – czy w rzeczywistości są możliwe do wykonania i sprawiają, że podróż staje się optymalna, a przez to, najzwyczajniej w świecie, szybsza.
Bazując na opiniach użytkowników, nastąpiło wprowadzenie kolejnych ulepszeń, jak dodanie pliku shapex.txt zawierającego realistyczne przebiegi linii autobusowych, czy zostały również poprawione lokalizacje przystanków. W międzyczasie trwały również testy dodatkowej usługi obejmującej manualne wprowadzanie alertów dotyczących świadczonych usług, takich jak awarie, korki czy remonty.
Po upewnieniu się, że przygotowany zestaw plików jest tym ostatecznym, który będzie użyty jako pierwszy dostępny publicznie po wdrożeniu, nastąpiło zgłoszenie tego faktu do zespołu supportu dostawcy narzędzia, którego pracownicy sprawdzili kilkukrotnie jakość dostarczonych danych i przekazali wskazówki pomocne w celu ulepszenia poprawności danych. Na tym etapie, po wprowadzeniu wszystkich poprawek, nastąpiło „zamrożenie” danych i oczekiwanie na przetworzenie przez serwery Google i pojawienie się w wynikach wyszukiwania wszystkich użytkowników Google Maps.
Smaczku dodaje możliwość customizacji takich elementów jak kolor poszczególnych linii czy wariantowość wyświetlania ich nazw.
Samo uruchomienie nastąpiło gładko i bez szczególnych problemów. Już od pierwszego dnia dostępności dla użytkowników można było zaobserwować rosnące wskaźniki wyszukiwań w statystykach, które są integralną częścią panelu narzędzia.
Co dalej?
Tak naprawdę, mimomimo że uważamy, że implementacja została uznana za zakończoną, to proces ten nigdy się nie kończy. Stały nadzór nad kolejnymi aktualizacjami rozkładów jazdy, monitorowanie feedbacku od wszystkich interesariuszy projektu – osób po stronie klienta, użytkowników oraz przedstawicieli dostawcy rozwiązania czy też ulepszanie usability i wdrażanie kolejnych komponentów – to zadania i czynności, które znajdują się w fazie prowdrożeniowej. Niech za przykład posłuży wydzielenie osobnych peronów przystankowych dla poszczególnych linii autobusowych na jednej z pętli i pogrupowanie ich w stację; integracja z dostępnymi feedami innych przedsiębiorstw operujących na terenie Wieliczki – Kolei Małopolskich z autobusowymi liniami dowozowymi czy przecież Zarządowi Transportu Publicznego, będącego organizatorem komunikacji miejskiej na terenie Krakowa i gmin aglomeracji krakowskiej, które z Krakowem podpisały umowy o wspólnej polityce transportowej, czy na końcu wdrożenie usług automatycznego wskazywania i przesyłania położenia poszczególnych pojazdów, przez co wyniki wyszukiwania przestawiałby realne, a nie rozkładowe czasy odjazdu.
Implementację tę w mojej ocenie można uznać za zakończoną sukcesem. Niewątpliwie do tego przyczyniła się doskonała współpraca zarówno z klientem jak i dostawą usług, responsywność i otwartość na sugestie oraz mały (ilościowo) zakres wdrożenia, co było bardzo ważne ze względu na to, iż było to moje pierwsze kompleksowe usług podmiotu trzeciego. Co warto podkreślić, od rozpoczęcia procesu do osiągnięcia kamienia milowego w postaci opublikowania dla wszystkich użytkowników Google Maps minął okrągły miesiąc, co pokazuje, że zachowując jakość tworzonych rozwiązań, i przy dobrej woli klienta, jesteśmy w stanie wdrożyć rozwiązania nawet takich gigantów jak Google.
Feed dostępny jest do pobrania w ramach licencji CC BY-NC-SA 4.0 na stronie gtfs.pÿrfekt.
Narzędzia
XLS Tools for Google Transit Feed Specification (GTFS) – zestaw dwóch skoroszytów w Excelu służących do przygotowywania podstawowych plików na podstawie rozkładów jazdy [strona autora].
kml-to-gtfs-shapes – narzędzie do generowania ścieżek z plików KML.
transitfeed
Jest to zestaw narzędzi współtworzony przez Google, służący do pracy nad feedem w formacie GTFS.
- TransitFeed – biblioteka Pythona służąca do odczytu, zapisu i walidowania feedu
- FeedValidator – narzędzie działające w linii poleceń, które sprawdza feed pod kątem ewentualnym problemów
- ScheduleViewer – aplikacja pozwalająca przeglądanie połączeń na mapie za pomocą przeglądarki internetowej. Tworzy lokalny serwer.
- KMLWriter – aplikacja wykreślająca położenia przystanków z feedu w pliku KML, który można przeglądać w programie Google Earth.
- Merge – łączy dwa feedy w jeden.
- GoogleRandomQueries – program generujący losowe zapytania dla wyszukiwania połączeń w Google Maps dla adresów leżących w zasięgu przystanków z feedu.
- UnusualTripFilter – służy do przypisywania wartości trip_type w zależności od tego, jak często używany jest wzorzec podróży.
Warto zobaczyć
GTFS.pl – hurtownia znakomitej większości polskich feedów w formacie GTFS.
r/transit – subreddit o transporcie publicznym. Charakteryzuje się otwartą społecznością z całego świata.
Wszystkie znaki towarowe oraz nazwy produktów są zastrzeżone i należą do właściwych podmiotów. Autor zastrzega brak powiązań zarówno z klientami, jak i dostawcami usług.