Warszawa - komunikacja miejska

@kocio: nei wystarcza daty wykonania edycji w OSM?

Ogolnie nadal jestem zdania ze trzymanie aktualnych co do dnia tras w OSM to przesada, i ze konkretna trasa powinna byc wyznaczana np. po stronie preprocessingu w aplikacjach na podstawie danych OSM i transiki.

@koszatek, bo dyskusja dotyczyla, wydaje mi sie, sprawdzania czy dana relacja jest prawidlowa i czy nadal zgadza sie z rozkladem wedlug ZTM. Wiec chodziloby o porownanie tego co jest w relacji z tym co powinno w niej byc.

Jest jeszcze jeden problem z tymi schematami - zakładałem, że w danej chwili jest aktywny tylko jeden, ale może być i tak, że np. przed południem autobus jeździ do pętli A, a po południu do pętli B (albo co drugi kurs, albo raz w tygodniu - itp.). Myślę, że trzeba by te trasy lub odcinki tras odpowiednio opisać w ref, np. “111 (sb-nd)”, żeby było widać od razu na planie, że to wariant.

Ale to po co wtedy routing? Z relacji wyciągamy listę ulic (nazwanych, więc odpadają wszelkie łączniki itp), z danych ZTM wywalamy zawrotki itp, jakoś stwierdzamy, którą relację z którym schematem porównać i porównujemy po nazwach (tu też trochę zabawy, bo w OSM dążymy do nazw pełnych, a ZTM ogranicza się jak może).

Edit:
Chyba że chodzi o pomysł, żeby brać listę przystanków z ZTM, wyszukać je w OSM (jak? chyba nie ma wszędzie nazw?), wyszukać routingiem domniemaną trasę i porównać z relacją? Hmmmm, z tramwajami to ma sens, ale z autobusami chyba jest za dużo możliwości…

Data edycji może wypaść np. następnego dnia, a tu chodzi o to, kiedy ZTM ostatnio odświeżał, a nie kiedy my, bo jak wtedy byśmy sprawdzali, czy mamy aktualną wersję?

Transiki jeszcze nie mamy i na razie nie widzę, żeby ktoś chciał wziąć na siebie postawienie pionierskiego serwisu - Steve odpadł i nikt nie przejął idei, a w tym wątku także nikt się nie deklarował.

Nie rozumiem dlaczego niby przesada i jaką wobec tego częstotliwość aktualizacji proponujesz? Moim zdaniem powinna być taka, na jaką nam pozwalają narzędzia i zasoby ludzkie do śledzenia - jeśli z tymi zasobami się uda np. w minutę po ogłoszeniu w ZTM, to dlaczego mielibyśmy tego nie mieć?

Mozna i tak, ale wydaje mi sie ze to bedzie mniej niezawodne a podobnie skomplikowane, i nie bedzie przy okzji ulatwialo tworzenia czy automatycznego poprawianie tych relacji.

Natomiast porownywanie nazw skroconych z nieskroconymi powinno proste, generalnie zawsze przy porownywaniu nazw w bazie czy w wyszukiwarkach (i szczegolnie w narzedziach czy wizualizacjach do sprawdzania jakosci np. adresow bez ulic) nalezy skracac co sie da (w tym slowa juz skrocone, ktore da sie skrocic jeszcze bardziej), ignorowac interpunkcje, pomijac slowa w nawiasach i ignorowac kolejnosc czlonow. Nie wiem czy nie warto tego powtarzanego kodu umiescic w jakiejs biblioteczce bo ludzie czesto zapominaja.

O to mi wlasnie chodzi. Jesli nie mamy nazw przystankow to prawdopodbnie lepiej je uzupelnic zanim zaczniemy sie martwic trasami :stuck_out_tongue:

ZTM ogłasza masę zmian typu weekendowe objazdy, trasa zmieniona wchodzi w życie o północy. Na szczęście ZTM oznakowuje, które zmiany są tymczasowe.

@balrog-kun
Tylko to z kolei będzie oparte o prawidłowe wyszukanie przystanku. Zespołów jest ok. 2200 a peronów zapewne ze 3 razy tyle.

Ale i tak chcemy te wszystkie przystanki mieć, więc czemu nie zacząć od tej strony? Przystanki się tak szybko nie zmieniają i da się z nich generować linie, natomiast linie zmieniają się często i nie da się z nich wyznaczyć dokładnych przystanków.

Ciekawe może być to trasowanie autobusów, ponieważ mogą wtedy wyjść różne nietypowe oznakowania ulic, na przykład że droga tylko dla autobusów, dopuszczalna masa tylko dla pojazdów osobowych albo coś innego w tym stylu.

Data absolutnie ostatniej edycji moze wypasc, ale nie data np. ostatniej edycji przez automat o konkretnym nicku, czy changesetu otagownego w odpowiedni sposob.

Bo wtedy to zaczyna juz byc mirrorowanie czyjejs prywatnej bazy danych, ktora jest ustalana przez wlasciciela arbitralnie. Np. jesli ZTM oglosil o polnocy w piatek, ze zmienia sie rozklad jazdy w dni pracujace danej linii dziennej to nie ma to nic wspolnego z rzeczywistoscia az do poniedzialku o 5-6 rano. Do tego tez dyskutowane bylo wiele razy zalozenie, ze nie mapujemy rzeczy chwilowych, np. polozenia obiektow ruchomych, a zmiany rozkladow moga byc bardzo chwilowe. Ale tez prawda, ze nie mamy definicji co jest chwilowe (w UMP np. jest ustalone, ze remonty tylko dluzsze niz 14 dni).

I czy to, ze np. ja nie chce ustawic bazy danych o trasach samolotow albo innej specjalistycznej automatycznie znaczy ze moge je pakowac do bazy OSM?

Hm - nie rozumiem, coś mi się tu zaciemniło. Data zmiany w ZTM to dla naszego automatu numer wersji - porównuje czy mamy tę samą wersję i mamy pewność czy mamy aktualne dane. Data edycji nie daje tej pewności (plus jest mniej human readable).

Znów proszę jaśniej… A jak ściągamy np. co tydzień, to jest w porządku - z tą samą prywatną i arbitralną bazą? A po tygodniu i tak robisz mirror, tylko z opóźnieniem.

Nie nawołuję bynajmniej do uwzględniania wszystkich planowanych zmian - wystarczy uwzględniać powiedzmy na najbliższy dzień.

Przez te kilka lat edytowania OSM nie uczestniczyłem w dyskusjach, więc siłą rzeczy jest to dla mnie nowe. Ale rzeczywiście, jeśli z jakichś powodów nie chcemy aktualizować rzeczy chwilowych, to lepiej mieć roboczą definicję (być może różną dla różnego rodzaju zjawisk).

Znów nie zrozumiałem przykładu - możesz jaśniej?

Sądząc po tej wymianie zdań i po wątku prawnym sądzę, że (w wikipedystycznej terminologii) jesteś raczej delecjonistą, a ja bardziej inkluzjonistą. To wróży częste konflikty w dyskusji. :slight_smile:

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: