Problemy z implementacją GTFS w Białymstoku
Czasy odjazdów zdefiniowane w calendar_dates.txt zamiast w calendar.txt
Jak wiemy, dane GTFS dla Białostockiej Komunikacji Miejskiej są dostępne tutaj: https://komunikacja.bialystok.pl/cms/File/download/gtfs/google_transit.zip
Po pobraniu archiwum .zip i rozpakowaniu go, ukażą nam się pliki:
- agency.txt
- calendar_dates.txt
- routes.txt
- shapes.txt
- stops.txt
- stop_times.txt
- trips.txt
W dokumentacji (link niżej do oryginału w j. ang.) GTFS jest zawarty opis tego, za co każdy z tych plików odpowiada.
https://gtfs.org/schedule/reference/#dataset-files
Zwróćmy uwagę, że calendar.txt nie ma w pobranym archiwum .zip, natomiast calendar_dates.txt jest.
GTFS pozwala na taką sytuację - jak można przeczytać w https://gtfs.org/schedule/reference/#calendar_datestxt:
Alternate: Omit calendar.txt, and specify each date of service in calendar_dates.txt. This allows for considerable service variation and accommodates service without normal weekly schedules. In this case service_id is an ID.
Jednak sam fakt, że GTFS dopuszcza taką sytuację, nie oznacza, że pasuje ona do autobusów (bo w końcu rozmawiamy o BKM).
Przeczytawszy powyższy cytat od razu widać, że tryb w którym to calendar.txt nie istnieje, a calendar_dates.txt już tak, jest przeznaczony
dla środków transportu, które kursują nieregularnie. Na przykład - statek przeprawiający ludzi przez rzekę tylko wtedy kiedy operator statku wie,
że danego dnia będą turnusy turystyczne. Czyli statek wyjątkowo kursuje w danym dniu.
Innymi słowy, calendar_dates.txt służy do definiowania wyjątków w normalnym kursowaniu.
Jeżeli połączenie nie ma pliku calendar.txt, to znaczy że z reguły nie kursuje, a calendar_dates.txt definiuje w w którym dniu
i o której godzinie wyjątkowo połączenie zostanie wykonane.
Autobusy miejskie jeżdżą jednak w stale określonych godzinach, no i wyjątkowo kurs może się nie odbyć,
bo na przykład MPO nie odśnieżyło miasta. W przypadu BKM, plik calendar.txt powinien definiować planowe kursy tak,
jak są one przedstawione w https://www.komunikacja.bialystok.pl/?page=rozklad_jazdy, i ewentualnie calendar_dates.txt powinien
definiować odstępstwa od planowych rozkładów (np. “3 grudnia linia nr. 5 będzie jechała trasą tą i tą, bo przez miasto biegnie maraton”).
Oczywiście calendar_dates.txt jest trochę wisienką na torcie, bo najważniejsze, żeby standardowy rozkład jazdy był po prostu w calendar.txt.
Dynamiczne generowanie wyjątków w planie wymagałoby integracji z istniejącymi systemami informatycznymi BKMu.
Podsumowując, obecna sytuacja, gdzie wszystkie odjazdy są zdefiniowane w calendar_dates.txt mówi jakoby autobus wyjątkowo odjeżdżał danego dnia,
mimo, że jest to kurs według planowego rozkładu.
Przyjrzyjmy się jeszcze zawratości pierwszych dwóch i ostatniej linijki calendar_dates.txt BKM, który pobrałem przed chwilą:
service_id,date,exception_type
P_903,20240115,1
[...]
P_903,20240409,1
Jak widać, przejazdy są naiwnie generowane na 85 dni do przodu (15 stycznia 2024 <-> 9 kwietnia 2024).
“Panie a kogo to obchodzi? Toż działa”
Pierwszym problem jest następujący:
Google Maps korzysta z białostockiego GTFS w celu podpowiedzenia pasażerom jak dotrzeć komunikacją miejską do danego celu. Przypominam, że kursy są generowane “tylko” 85 dni do przodu.
Jeżeli np. przyszły turysta zdecyduje się sprawdzić ewentualną trasę autobusów w dniu swojego przyjazdu za np. 4 miesiące (czyli później niż 9 kwietnia 2024 z przykładu wyżej - Google Maps daje taką możliwość), to nie ukażą mu się żadne przejazdy autobusem. Właśnie sprawdziłem i widzę, że Google Maps wtedy sugeruje tylko FREENOW i Bolt.
Przyznam że wyżej opisana sytuacja jest niebotycznie naciągana, byleby tylko znaleźć wadę w białostockim GTFS. Niemniej jednak
zmiana na poprawniejszy calendar.txt, który opisuje odjazdy cyklicznie (poniedziałek, wtorek…,
zamiast “wyjątkowo 2-go stycznia autobus pojedzie…”) pomogłaby tego uniknąć. Nie ważne jak odległą datę byśmy wybrali,
to liczyłoby się tylko który to jest dzień tygodnia, a nie ile dni w przyszłości jest ta data.
Drugi problem jest następujący: GTFS jako otwarty format danych może być używany nie tylko przez Google Maps, ale też i przez inne programy. Na przykład, popularne oprogramowanie do zarządzania smart domem - Home Assistant - posiada parę wtyczek wyświetlających najbliższy odjazd autobusu danej linii na danym przystanku. Taką informację można potem sprawdzić w głównym panelu Home Assistant na telefonie.
Jedną z takich wtyczek jest np. https://www.home-assistant.io/integrations/gtfs.
Problem jest taki, że tego typu wtyczki są raczej nastawione, że treść otrzymanego GTFS będzie właśnie w typowym dla transportu
formacie używającym jedynie calendar.txt, a nie w dziwnym calendar_dates.txt. Z jednej strony - źle bo wtyczka nie wspiera
obu formatów (faktycznie, w kodzie wtyczki calendar_dates.txt nie jest w ogóle rozpatrywany), a z drugiej, trudno mi zgłosić
raport błędu do autora mówiąc “słuchaj no, bo my tu w Białymstoku robimy rzeczy trochę inaczej i autobusy kursują wyjątkowo tylko
85 dni do przodu - ciągle żyjemy w strachu czy będą kursować później”.
TODO Opisać fakt, że kursy skrócone przez zjazd do zajezdni widnieją w GTFS jako pełne kursy
EDIT: Hm, chyba jest jednak w porządku tj. jeżeli w oficjalnym rozkładzie jazdy kurs jest oznaczony literą “z” i np. kończy się w połowie regularnej trasy, to w GTFS będzie on widniał jako pełny kurs.
Tworzy to sytuację w której Google Maps pokaże nam, że możemy danym kursem dojechać w pewne miejsce, a tu okaże się, że trzeba będzie wysiąć w połowie i sobie poradzić, czy też się spóźnić.