fbpx

A może tak Google Transit?

Od kilkunastu lat coraz bardziej popularnym staje się wykorzystywanie internetowych serwisów dostarczających mapy, jak Google Maps, do wyszukiwania idealnych połączeń pomiędzy dwoma punktami – miastami czy też adresami. Pomimo, że na początku oferowały one jedynie funkcjonalość pozwalającą na określenie najlepszej trasy przejazdu samochodem albo rowerem, tak obecnie na popularności zyskuje możliwość doboru środka transportu publicznego, który pomoże nam dostać się do celu.

Kiedyś podstawowym narzędziem służącym do przeglądania rozkładów jazdy były strony przewoźników(przed komunikacyjną rewolucją) oraz organizatorów transportu publicznego(po niej). Wraz z rozwojem telefonów i upowszechnianiem się dostępu do internetu w smartfonach pojawiły się aplikacje mmpk – pozwalające na przeglądanie rozkładów jazdy – czy też, bardziej obecnie popularne jakdojade.pl, które służy do wyszukiwania optymalnych połączeń tramwajowych, autobusowych i kolejowych.

Obecnie, najpopularniejszą usługą pozwalającą na wyszukiwanie połączeń jest Google Transit, będący składową Google Maps. Dzięki niemu, za pomocą kilku kliknięć możemy uzyskać wskazówki dojazdy komunikacją publiczną i porównać je wynikami wyszukiwania dla pokonania tej samej drogi pieszo, autem czy też rowerem.

Google Transit korzysta z struktury danych zapisanych w formacie GTFS, który jest natywną formą zapisu danych dla tej usługi. Historia nie jest zbyt długa i zaczęła się w 2005 roku, jako poboczny projekt pracownika Google’a, Chrisa Harrelsona, który rozpoczął poszukiwanie sposobów włączania danych tranzytowych do Google Maps, gdy usłyszał o tym pomyśle od Tima i Bibiany McHugh, menedżerów IT w TriMet, organizatora tranportu publicznego z Portland. McHugh zwracał też w rozmowach uwagę na frustrację związanę ze znalezieniem wskazówek dojazdu w nieznanych miastach, podczas gdy popularne usługi map już dawały łatwą w użyciu nawigację.

Podgląd bieżących odjazdów tramwajów z pobliskiego przystanku? Czemu nie!

Bibiana i Tim McHugh ostatecznie skontaktowali się z Google i udostępnili firmie eksport danych CSM z harmonogramu TriMet. W grudniu 2005 r. Portland stało się pierwszym miastem, które pojawiło się w pierwszej wersji Google “Transit Trip Planner”. We wrześniu 2006 r. do Google Tripit Trip Planner dodano kolejne pięć miast w Stanach Zjednoczonych, a format danych został wydany jako specyfikacja pliku danych Google Transit.

W Stanach Zjednoczonych nie było żadnego standardu dla rozkładów jazdy publicznej przed pojawieniem się GTFS. Zdaniem wieloletniego menedżera strony internetowej BART (Bay Area Rapid Transit – organizator tranposrtu publicznego regionu Zatoki San Francisco), Timothy’ego Moore’a, przed pojawieniem się GTFS, BART musiał zapewnić innym konsumentom danych różne formaty. Przez to właśnie, ​​standaryzowany format tranzytowy stał się bardzo pożądany. Publiczna i ogólnodostępna specyfikacja formatu, jak również dostępność harmonogramów GTFS, sprawiły, że programiści oparli swoje oprogramowanie związane z transportem na formacie. Ze względu na wspólny format danych, do którego kolejno powstałe aplikacje się stosują, rozwiązania nie muszą być dostosowane do jednego operatora transportu, ale można je łatwo rozszerzyć do dowolnego regionu, w którym dostępny jest kanał GTFS.

Ze względu na szerokie zastosowanie tego formatu, część nazwy Google została uznana za niewłaściwą, co doprowadziło nawet do tego, że ​​niektórzy potencjalni użytkownicy nie chcą przyjąć plików GTFS. W związku z tym zaproponowano zmianę nazwy specyfikacji na General Transit Feed Specification w 2009 r.

Struktura danych

Feed GTFS to zbiór co najmniej sześciu i do 13 plików CSV (z rozszerzeniem .txt) zawartych w pliku .zip. Preferowane kodowanie znaków to UTF-8. Łącznie powiązane tabele CSV opisują zaplanowane operacje systemu transportowego jako widoczne dla podróżnych i kierowców. Specyfikacja została zaprojektowana tak, aby zapewnić funkcjonalność planowania podróży, ale jest również przydatna w przypadku innych aplikacji, takich jak analiza poziomów usług i niektóre ogólne miary wydajności. W przeciwieństwie do standardów wymiany europejskiej branży tranzytowej, takich jak Transmodel lub VDV-45X, GTFS obejmuje tylko zaplanowane operacje, które mają być dystrybuowane wśród kierująych pojazdami. Jest również ograniczony do zaplanowanych informacji i nie zawiera informacji w czasie rzeczywistym. Jednak informacje w czasie rzeczywistym mogą być powiązane z harmonogramami GTFS zgodnie z powiązaną specyfikacją GTFS-realtime.

Model struktury danych GTFS stworzony przez Martina Davisa, za jego blogiem.

Poniżej znajdują się opisy tabel wymaganych dla prawidłowego pliku danych GTFS. Każda tabela to dosłownie tekstowy plik CSV, którego nazwa pliku jest nazwą tabeli, z rozszerzeniem “.txt”. Tak więc – tabela agencja to plik CSV o nazwie agency.txt, który powininen zostać umieszczony w prawidłowym pliku danych GTFS.

Tabele obowiązkowe

agency
Dostarcza informację o organizatorze komunikacji publicznej, takie jaknazwę, stronę internetową i dane kontaktowe.

routes
Tabela tras określająca różne trasy. Służy też do rozróżniania tras, z których kilka może należeć do pojedynczej trasy.

trips
Poszczególne kursy w ramach danych tras/linii.

stop_times
Godziny przyjazdów i odjazdów z danych przystanków dla poszczególnych kursów linii.

stops
Tabela przystanków określa położenie geograficzne każdego rzeczywistego przystanku lub stacji w systemie tranportowym, a także, opcjonalnie, niektóre udogodnienia związane z tymi przystankami.

calendar
Tabela kalendarza określa wzorce usług, które działają cyklicznie, takie jak na przykład każdy dzień tygodnia. Wzorce usług, które nie powtarzają się tak, jak w przypadku jednorazowego zdarzenia specjalnego, zostaną zdefiniowane w tabeli calendar_dates.

Tabele dodatkowe

calendar_dates
Zapis wyjątków funkcjonowania komunikacji (np. świąt, dni wolnych od pracy, sylwestra).

fare_attributes
Informacja o taryfach obowiązujących na poszczególnych trasach.

fare_rules
Zasady obowiązywania taryf przewozowych (odcinkowe, przesiadkowe).

shapes
Zasady rysowania odcink ówna mapie w celu przedstawienia tras linii.

frequencies
Częstotliwość kursowania dla lini mających ją stałą.

transfers
Zasady łączenia większej ilości przystanków w grupy przesiadkowe.

feed_info
Informacje uzupełniające o zasobie (kontakt, autor, data obowiązywania).

Co dalej?

Na pierwszy rzut oka, wydawać by się mogło, że o ile za formatem GTFS stoi prosta idea – bo co to za filozofia przekopiować tabelki z rozkładami jazdy do Excela – tak po bliższym przyjrzeniu się strukturze i zasadom stojącym za formatem klaruje się obraz nader skomplikowanego tworu, któremu trudno sprostać. Istnieje niestety tylko kilka dobrych przewodników, które pomagają stawiać pierwsze kroki w tej materii:
1. Kurs Banku Światowego
2. Dokumentacja RTAP
3. Opis formatu na stronie Google’a

Jak widać, nie jest to twór, którego nie sposób nie ugryźć. Przy odrobinie skupienia, wolnego czasu oraz samozapału wykonanie prostego zestawu tabel dla np. jednej linii autobusu czy tramwaju może stanowić wyzwanie, które da się osiągnąć.

Zobacz także:

Google Transit

TransitWiki

Źródła:

https://developers.google.com/transit/gtfs/reference/#general_transit_feed_specification_reference

Garg, Avichal. “Public Transit via Google”Official Google Blog. Retrieved 14 March 2016

Roush, Wade (2012). “Welcome to Google transit: How (and why) the search giant is remapping public transportation” (PDF). Community Transportation: 3.

Leave a Comment.