Warszawa - komunikacja miejska

Jesli zakladamy, ze osoby czy automaty ktore zajmuja sie aktulizacja tych relacji wrzucja dane aktualne na dany moment, to data edycji jest zawsze wczesniejsza niz data wprowadzenia przez ZTM nowszego rozkladu i nie pozniejsza niz data wprowadzenia poprzedniego. No ale prawda, ze jest to mniej human readable przy aktualnych narzedziach.

Bardziej niz o czestotliwosc chodzi mi o niedodawanie zmian tymczasowych ale wracamy do braku dobrej definicji. Wedlug tego co napisal koszatek takie zmiany sa jakos oznaczone w rozkladach ZTM. Ale to, ze w ogole mowimy o mirrorowaniu i czestotliwosci powinno nam dac do myslenia czy w ogole to sa dane geograficzne i czy osm to dobre miejsce na nie, dobry schemat danych (w porownaniu np. z GTFS) itp. Chodzi tez o to, zeby ktos nie zaczal polegac na OSM jako zrodle danych o pracy ZTM. Moze sie czepiam.

Chodzi mi tylko o Twoje zdanie

jako usprawiedliwienie w pewnym sensie wykorzystania OSM jako transiki z dosyc blachego powodu.

Oczywiscie nie mam zamiaru niczego usuwac z osm.

Z tymi rozkładami i trasami to jest tak. Prowadziłem w latach 2000-2003 serwis z wszystkimi danymi importowanymi z ZTM - pełne parsowanie tras i rozkładów jazdy, łączenie ich w tabele na kształt kolejowego SRJP, wyliczanie częstotliwości, szablonów czasu przejazdu itp. Powiem tak: parsowanie htmla da się ogarnąć, ale trzeba tego doglądać i na bieżąco wprowadzać poprawki do skryptów. Nie można tego zostawić na miesiąc i nic nie robić, bo zawsze coś się posypie. Rozkłady były wrzucane czasem na kilka dni naprzód, czasem na parę godzin przed terminem w postaci całego katalogu zawierającego zarówno dane zmienione jak i niezmienione. Pobierałem i parsowałem automatem zawsze wszystko (do dziś mam skrypt pobierający rozkłady, trochę się tych paczek zebrało od 2000 roku do dziś…), ale jak chciało się zrobić to dobrze, to sporo było nietypowych rzeczy do obsłużenia np. dopiski dotyczące wybranych kursów albo całej linii w rodzaju “kursuje w dni szkolne” albo “nie kursuje w drugi dzień wielkanocy”, przy czym ZTM często zmienia sformułowania tych dopisków albo w różnych liniach stosuje różne sformułowania dotyczące tak naprawdę tego samego.
Do tego dochodzą zmiany weekendowe, a ZTM wrzuca niby całą paczkę, ale okrojoną o te linie, które rozkładowo w weekend nie kursują. Robi się więc burdel na maksa z tymi zakresami obowiązywania, bo taka linia (najczęściej 4** lub 3**) nagle “znika” z dnia na dzień z rozkładu a potem od poniedziałku wraca z rozkładem niezmienionym. Więc w takim przypadku zasadniczo nie powinna w weekend znikać z mojego serwisu, bo nie została wycofana, tylko po prostu w ten dzień nie kursuje, ale przecież ktoś w sobotę może chcieć sprawdzić, czym może dojechać w poniedziałek.
Jeśli ktoś chciałby się bawić w zbieranie danych o rozkładach i trasach, będzie musiał się z takimi problemami zmierzyć.

Edit: przynajmniej kiedyś tak było. Może teraz ZTM wrzuca pełne paczki. Ale zawsze to było tak, że ZTM lubił czymś zaskakiwać i trzeba było szybko znaleźć rozwiązanie pod groźbą publikowania w moim serwisie nieaktualnych lub błędnych danych. A ponieważ nie miałem nieraz czasu by tego doglądać, w końcu odpuściłem.

Po zastanowieniu coraz bardziej mi się podoba idea tagowania datą ważności - po pierwsze generalnie boję się “botokracji”, tzn. nie samych botów, bo je akurat bardzo lubię, tylko poleganiu na rzeczach automatycznych bez łatwej możliwości skontrolowania ręcznie, a po drugie ostatni post koszatka każe mi podchodzić ze zdwojoną ostrożnością do danych z ZTM. Traktuję te tagi z datą ważności jako debugowanie.

Nawet jeśli udoskonalimy narzędzia, to ZTM nadal może być nieprzewidywalny, a OSM siłą rzeczy będzie też robione głównie ręcznie, więc nie chciałbym, żeby utrudniać ludziom orientację w części danych (nie uniemożliwiać - nadal mogliby sprawdzać, tylko trudniej). To by mogło prowadzić do “zawłaszczenia” tej działki przez operatora bota, co w razie problemów zostawia nas z jedną osobą zorientowaną, a znam osobiście przypadek, że autor kodu po paru latach już nie pamięta swojego kodu i nie chce go naprawiać.

Ja nie odbieram tego jako czepialstwa, to słuszny powód do ostrożności. Z tym, że tu jesteśmy bezpieczni, bo - poza samym ZTM - są przynajmniej dwa popularne serwisy, czyli JakDojade (promowane przez ZTM na ich stronach!) oraz Transportoid, a u nas warstwa transportowa nie jest domyślnie widoczna. One przecież mają nawet czasy odjazdu, koszty biletów, ulubione przystanki i aplikacje na komórkę - słowem choćbyśmy się nagle sprężyli, to i tak nie odbierzemy im użyteczności ani użytkowników - to na razie nawet nie ta liga.

Pytanie czy to dane geograficzne jest do zastanowienia, ale bez godzin odjazdu to MSZ owszem, bo komunikacja dotyczy właśnie pokonywania przestrzeni - a nawet jeśli z godzinami, to przecież rysuje się nam już OSM 4D (http://wiki.openstreetmap.org/wiki/Pl:OSM-4D). Sieć komunikacji miejskiej to szczególny przypadek dróg i ścieżek dla pozostałych pojazdów. Ale jest też drugi argument - i np. mnie on tu właśnie zwabił: warstwa transportu publicznego już istnieje, tylko jest w Warszawie bardzo niekompletna. Pytanie filozoficzne - czy lepiej mieć dane, które będą się zmieniać, ale dążyć do kompletności, czy lepiej nie mieć ich w ogóle - rozstrzygam w pierwszy sposób: z powodów obiektywnych nie będzie idealnie, ale warto próbować podejść jak najbliżej.

Myślę też o tym, że definicja dokładności się rozszerza: kiedyś wystarczały nam przebiegi dróg, ale pojawiły się dokładniejsze zdjęcia satelitarne i teraz chcemy rozrysowywać poszczególne pasy i kształty poboczy. Myślę, że podobnie będzie z tymczasowością: jest więcej chętnych, nowe serwery mogą szybciej renderować itp. Nie mówię, że musimy od razu chwytać realtime - jeśli ustalimy, że należy unikać zbyt częstych zmian, to ja ten kompromis uznam bez problemu (jak bym chciał, to bym se robił własną mapę, tylko wolę wspólnie), ale moim zdaniem cały projekt będzie się rozwijać właśnie w kierunku większej “rozdzielczości” czasoprzestrzennej.

Nie do końca chwytam po co taka osobna baza (czyli nie nadążam za argumentacją Steve’a), więc dla mnie wrzucanie tych danych do OSM jest po prostu naturalne, a nie zastępcze. Na razie jeśli widziałbym jakąś granicę mędzy tymi projektami, to żeby w Transiki były godziny odjazdów, a w OSM na razie nie. A póki co mamy w aglomeracji warszawskiej tyle roboty z przystankami i liniami, że jak już dojdziemy do godzin odjazdów, będzie się można spokojnie zastanowić co dalej.

OSM nie jest przystosowane do dodawania rozkładów jazdy i nigdy nie będzie (chyba, że nowe api) każdy autobus musiłby być osobną relacją na jednej trasie, zaś przystanki miałyby rolę godziny odjazdu. Uważasz, że nie zrobiłby się burdel? Ciężko się zarządza 5 relacjami na jednej drodze, a dodaj sobie do tego 5 tras4 autobusy na godzinę24h Bosko!

Jestem za reaktywacją Transiki! Źródła czekają, a to może być fajny projekt dla Polski :slight_smile:

Zapewne sporo by ułatwiło, gdyby ZTM udostęnił oficjalnie dane nie w htmlu a w jakimś łatwo parsowalnym formacie. W roku 2000 pisałem do nich, ale to pozostało bez odpowiedzi. Teraz są inne czasy, może stowarzyszenie zwróciłoby się do nich z prośbą? Jeśli działają i są przez nich jakoś wspierane serwisy typu jakdojade, to może techniczniei organizacyjnie są już gotowi na udostępnianie danych w innych formatach?

Właśnie wgryzam się w konstruowanie modeli S3DB, więc mam bardzo dobrą analogie: myślisz, że OSM jest dostosowane do 3D? To też jest rzeźbienie w miękkim i brązowym. Wyobraź sobie kilka warstw z częściowo pokrywającymi się krawędziami, przypisane do relacji typu “budynek”, gdzie w dodatku nie ma jak zdefiniować pochyłych ścian ani wypukłości i wgłębień gruntu, a to wszystko edytuje się narzędziami 2D typu JOSM…

Ale mnie to nie dziwi, bo tak właśnie się rozwijają zdrowe projekty społecznościowe: najpierw się robi coś bardzo prostego, co z grubsza działa, to przyciąga kolejnych ludzi, którzy to cyzelują, a w miarę pojawiania się kolejnych pomysłów szuka się sposobu, jak obejść ograniczenia pierwotnego modelu, i czasem (oczywiście nie zawsze i często etapami) kończy się to jego sporą przebudową.

Ja w sumie też, tzn. bardzo bym chciał przynajmniej zobaczyć, czy taki projekt się po prostu sprawdzi. Ale ponieważ nie widzę chętnych, to (pragmatycznie) na razie nie liczę na jego powstanie i koncentruję się na OSM, jak ograniczone by ono nie było.

Baza przecież może być powiązana z OSM. będę miał chwilę to pokażę jak to może wyglądać. Tu nie chodzi o to, że się nie da, ale gdy zrobi się zbyt duży burdel to będziemy bać się wprowadzać nowych mapowiczów, że coś zniszczą.

Aby pokazać, że tabliczki z odjazdami można fajnie zintegrować z OSM napisałem prostą stronkę.
http://osm.zz.mu/?relation=0&submit=OK

Nie ma tu żadnych danych oprócz tych przykładowych.
Jedna tabela to Trasy, w której są 2 pola id i osmId. OsmId reprezentuje id relacji w OSM. Każda trasa to jeden przejazd autobusu.

Druga tabela to przystanki. Posiada pola id, traceId, osmId, time1, time2, no. osmId to id przystanku w OSM. time1, time2 to czas przyjazdu i odjazdu oraz no reprezentuje kolejny numer przystanku aby posortować zatrzymania autobusu.

Z takiej bazy można spokojnie wyciągnąć kiedy dojedziemy na miejsce X jeśli wyjedziemy o godzinie Y. Można spokojnie zbudować tablicę odjazdów na podstawie id przystanku. gdyby się uprzeć to nawet routing na tym można zbudować na podobnej zasadzie jak na stronie jakdojade.pl

Jeśli byłoby zainteresowanie kilku osób to mozna pomyśleć nad tą stroną. Bo napisanie czegoś takiego to pewnie 2 dni roboty.

Struktury danych są bardziej złożone. Tu przykładowy rozkład jazdy (z fragmentem trasy, który jest wspólny dla obu kierunków): http://mb.waw.pl/inne/rozklad.png
A są bardziej pokopane trasy.

@koszatek:
Ogromne dzięki za pokazanie problemu z ZTM! No to wygląda mi na to, że naszych dyskusji nad częstością aktualizacji nie warto zamykać zanim się nie dowiemy jak obecnie ZTM się zachowuje i nawet powołanie Transiki nie załatwiłoby sprawy. Czy mógłbyś się przyjrzeć, czy teraz jest z ich rozkładami lepiej/gorzej/bez zmian. Byłoby super, gdybyś podrzucił jakieś ogólne statystyki ilu linii (i ew. których) dotyczą problemy ze swobodnymi opisami, weekendowe znikanie, wielowariantowe trasy, ogłaszanie w dziwnych momentach itp. To by nam dało orientację gdzie trzeba będzie kombinować i jak bardzo. Co do prośby o dostęp do dobrze parsowalnych danych z ZTM to myślę, że po kilkunastu latach warto znów spróbować. Stowarzyszenie może być tu dobrym wsparciem, ale sądzę, że tylko formalnym, tzn. napisz gotowe pismo i daj im znać, że takie chcesz oficjalnie puścić w imieniu stowarzyszenia.

Tak sobie myślę, że ciekawe jakie są doświadczenia innych miast w Polsce i na świecie z mapowaniem komunikacji publicznej, a zwłaszcza jak sobie radzą z kapryśnymi rozkładami jazdy. Macie pomysł kogo podpytać?

No tak ogólnie to też mozna załatwić pewnymi tagami, ale jeśli byłaby potrzeba stworzenia nawet od nowa takiego serwisu w stylu transiki to damy radę. Pytanie czy znajdą się ludzie, którzy będą to wszystko aktualizować. :confused:

No, wszystko da się zrobić, tylko niekiedy potrzeba trochę czasu. Na pewno więcej niż 2 dni.
Pomału próbuję ożywić moje stare skrypty, żeby zorientować się jak to teraz wygląda. Za tydzień powinienem już się orientować, jak to teraz wygląda, czy doszły jakieś nowe anomalie.
Przypomniała mi się jeszcze jedna stara historia, to już na 100% nieaktualne, ale też trochę krwi napsuło: mianowicie w prawie każdej paczce trafiały się uszkodzenia paru plików, jakby ktoś lub coś pozmieniało losowe bajty. I np. w efekcie programowi nie zgadzała się nazwa zespołu przystanków, bo dla komputera POWĄ@KOWSKA to nie to samo co POWĄZKOWSKA. Trzeba było robić kontrole zgodności, ale żeby było śmieszniej, to nazwy zespołów czasem naprawdę się zmieniały, więc musiałem napisać mechanizm zatwierdzania takiej faktycznej zmiany do bazy.

Spokojnie, nie spieszy się. :slight_smile: Lepiej to zrobić od razu systemowo i porządnie. Masz unikalne doświadczenie, idealne do zaplanowania prac nad warszawskim zbiorkomem, więc bardzo chętnie posłucham twoich uwag i oceny sytuacji.

Położenie przystanków z nazwami na terenie Warszawy jest na portalu http://www.mapa.um.warszawa.pl/ z adnotacją, że dane pochodzą z BGiK. Jeśli punkty adresowe zostały uznane za informację publiczną i można je było zaimportować do OSM, to może podobnie można będzie zrobić z przystankami?

I jak, udało ci się z grubsza zorientować, czy potrzeba więcej czasu? Jeśli tak to powiedz ile mniej więcej, bo chciałbym trzymać rękę na pulsie.

Na razie zauważyłem 1 nowe “dziwactwo”: trasa tworząca w pewnym miejscu pętelkę tzn. zalicza najpierw pewien przystanek na trasie, a potem wraca do niego jeszcze raz tą samą ulicą i tam kończy bieg (odcinek ulicy i przystanek powinny być w relacji 2 razy).
Zmieniły się pewne formaty informacji o trasie (inne znaczki niż były).
Reszta( jeśli chodzi o same trasy, bo z rozkładami gorzej) jest do ogarnięcia, w ciągu kilku dni powinienem zrobić uaktualniony parser tras.

Nawet nie zauważyłem, jak zleciał cały miesiąc! Udało ci się coś jeszcze? A przede wszystkim - jak po tym czasie oceniasz perspektywy?

W ramach odpoczynku siadłem sobie do stworzenia parsera, który by do pliku tekstowego zapisywał przystanki, numery Id…i inne ze strony ztmu (Nie jestem żadnym programistą, ale cośtam, czasem się bawię w pythonie).
Cały szczęśliwy po skończeniu ‘pracy’ wchodzę sobie na stronę ztmu, tak żeby sobie przejrzeć :slight_smile:

I tu patrzę, że w sekcji rozkłady jazdy >> do pobrania ztm udostępnia wszystko co nam potrzeba. (nie wiem jak długo to już tam wisi, ale pewnie od paru miesięcy)
Tak więc, na serwerze ftp ztmu są spakowane na każdy dzień pliki tekstowe zawierające rozkłady jazdy, wszystkie przystanki wraz z koordynatami GPS, trasy i…tutaj jest wszystko opisane.

Nic tylko wyciągać te dane i wprost na mapy!
Tylko potrzeb kompetentych, którzy znają się i umieją takie rzeczy pisać…i oczywiście mają czas :slight_smile:
Niby wszystko ładnie, tylko to nie takie proste taki parser zrobić :confused: …niestety

Bardzo się czuję zadowolony! Nie dość, że są dane, to - z tego co zrozumiałem - jest udzielona licencja na powszechne stosowanie, opis formatu i nawet określone dobre praktyki.

W tej sytuacji jest to robota mniej lub bardziej automatyczna. Jeśli coś trzeba ręcznie, to postaram się tym zająć, choć podejrzewam, że priorytetem na razie będzie naniesienie wszystkich przystanków, bo trasy między nimi można potem prowadzić jakimkolwiek routingiem (jak już pisałem - zasadniczo nie jest ważne którym dokładnie pasem jedzie autobus od punktu do punktu, tylko chodzi o wygenerowanie “wyobrażenia” ciągłej trasy pomiędzy przystankami).

Pomysł udostępnienia danych świetny, tylko ten format… mogli się postarać o jakiś xml, no ale dobre i to.
Trzeba by napisać parser do tego, ja ostatnio pisałem parser do plików tras, ale do tego trzeba będzie od nowa.