Komunikacja miejska dla niewidomych na terenie Śląska

Tagi [area:highway] zignoruj - to nie ma związku z przystankami ani komunikacją miejską.

Tam jeszcze brakuje chyba highway=platform.
Ale perony to już dodatkowe szczegóły - tam się nie podaje nazwy, refa itp.

We Wrocławiu przystanki są tagowane tak:
Autobusowe:
przystanek autobusowy: węzeł w miejscu słupka z rozkładem jazdy

highway=bus_stop
public_transport=platform
bus=yes
+dodatkowe tagi (name, ref, operator, network i inne)

miejsce zatrzymania autobusu: węzeł na drodze (ulicy) z tagami:

public_transport=stop_position
bus=yes
name=
ref=

Tramwajowe:
przystanek tramwajowy: węzeł w miejscu słupka z rozkładem jazdy

public_transport=platform
tram=yes
+dodatkowe tagi (name, ref, operator, network i inne)

miejsce zatrzymania tramwaju: węzeł na torowisku z tagami:

railway=tram_stop
public_transport=stop_position
tram=yes
name=
ref=

I w sumie tylko te 4 rzeczy będą ci potrzebne w tym imporcie. Lub może nawet 2 - miejsc zatrzymania raczej nie zaimportujesz z danych urzędowych.

Witajcie po dłuższej przerwie. Postanowiłem, że następnym razem jak do Was napiszę to już z jakimś konkretem.

Oto on: https://youtu.be/5eGUTa94dhw

W ciągu ostatniego pół roku utworzyliśmy prototyp systemu, który pozwoli na:

  1. Łączenie w graficzny sposób przystanków z systemu OSM z ZTM
  2. Sprawdzenie, czy połączenia robione przez użytkowników zostały wykonane poprawnie (drugi poziom weryfikacji)
  3. Podzielenie edytowanych danych na sektory
    • zastosowaliśmy kafelki. Więcej informacji.
    • podział mapy na kafelki zapewni sprawny podział pracy między użytkowników - każdy będzie edytował inny obszar
  4. Wgranie zmodyfikowanych danych na serwer OSM
    • podział na kafelki pozwala na wgrywanie mniejszych obszarów, zamiast wyrywkowo całej mapy Śląska

W dużym uproszczeniu, na mapie wyświetlają się przystanki z ZTM i OSM i użytkownik może je połączyć. Automatyczne łączenie się nie sprawdziło; algorytm nie dawał rady i łączył dane bez sensu, więc konieczne jest robienie tego ręcznie. Automatyczny import ZTM do OSM nie wchodzi w grę ze względu na słabą jakość pozycji przystanków nawet po inwentaryzacji - przystanki są w budynkach, na ulicy itd.

Nie planujemy modyfikować istniejących przystanków w OSM, a tylko dodać do nich dane.
Na podstawie danych z ZTM do każdego przystanku z OSM zostaną dodane następujące dane:

ref - identyfikator przystanku, zwykle kilkucyfrowy np. 1234567
local_ref - numer przystanku, zwykle 1 - 2 znaków np. 1, 2t

W przyszłości chcemy, aby można było dodawać nowe przystanki i usuwać z mapy te, których nie ma już w ZTM, ale na to przyjdzie jeszcze czas.

Nad wygenerowaniem pliku .osc z lokalnej bazy danych i wgrywaniem ich do OSM jeszcze pracujemy.

Mam do Was następujące pytania:

  1. Czy możemy przetestować nasze importy na jakimś serwerze testowym, czy raczej powinniśmy wgrywać zmiany bezpośrednio na OSM i je wycofywać gdy coś będzie nie tak?
    Znalazłem taką stronę https://wiki.openstreetmap.org/wiki/Using_the_dev_server. Wolałbym jednak nie stawiać swojego serwera, tylko skorzystać z jakiegoś istniejącego. Czy spotkaliście się z takim rozwiązaniem?
  2. Zdarzają się sytuacje, że jeden przystanek przynależy do dwóch stref np. Katowic i Rybnika. Zastanawiam się, czy wtedy w polu ref i local_ref umieścić dwa identyfikatory, czy może obok identyfikatora dodać informację o źródle?
ref = 12345, 33333
local_ref = 1t, 4

czy

ref = 12345(ztm), 33333(mzk)
local_ref = 1t(ztm), 4(mzk)

Pozdrowiam!

Myślę, że nie będzie problemu jeśli zaczniesz od najmniejszych porcji danych, czyli najpierw zaktualizuj tak jeden przystanek, sprawdź czy wszystko ok, potem zaktualizuj 3 przystanki, sprawdź czy wszystko ok, potem 10 itd.

Wysłane zmiany możesz sprawdzić tym narzędziem: https://overpass-api.de/achavi/?changeset=000000000
gdzie 000000000 to numer zestawu zmian

Serwer testowy jest tutaj: https://api06.dev.openstreetmap.org

ref:ztm=12345
ref:mzk=33333

Muszę sprawdzić, czy producenci nawigacji będą w stanie to przeczytać niewidomym…

Co do zasady, to oni powinni się dostosować do nas, a nie odwrotnie.

Właśnie;)

Ewentualnie możesz otagować:
ref=12345
ref:xxx=33333
jeśli któryś z nich można uznać za “główny/ważniejszy”.
Czy niewidomym potrzebne do czegoś te numery?

Maro Twoje rozwiązanie mi się podoba ponieważ czytniki dla niewidomych nie będą miały problemu przynajmniej z przeczytaniem tagu “local_ref”. Myślę, że to załatwia problem.
Niewidomym potrzebny jest tylko tag local_ref, ale ref też będziemy uzupełniać, żeby mieć połączenie z bazą danych ZTM. Jak np. w przyszłości zostanie usunięty (w ZTM) przystanek lub zmieniona nazwa to będziemy mogli to cyklicznie sprawdzać właśnie po tych identyfikatorach.

Tak też się staramy robić :slight_smile:

Ale takie identyfikatory kilku-cyfrowe chyba nie istnieją na terenie Śląska. Identyfikatory na terenie Metropolii są jednocyfrowe, można byłoby je przenieść do local_ref=, ale błędem byłoby dopisywanie jakiś fikcyjnych danych.

Każdy przystanek należący do ZTM, czyli znaczna większość przystanków na ternie Śląska posiada unikalny 6-ścio cyfrowy identyfikator.
Oprócz identyfikatora każdy przystanek posiada swój numer zwykle jednocyfrowy lub cyfrwa + litera “t” dla tramwajów.

Stąd można pobrać akutalne dane o przystankach ZTM: https://otwartedane.metropoliagzm.pl/dataset/rozklady-jazdy-i-lokalizacja-przystankow-gtfs

Przystanki są w pliku GtfsStops.txt.

Przykład przystanku zapisanego w pliku GtfsStops.txt:

161969,2t,Zabrze Karola Miarki,,50.307272,18.781744,/rozklady/przystanek/161969/,0

Unikalny identyfikator: 161969
Numer pryzstanku: 2t
Nazwa przystanku: Karola Miarki
Lat: 50.307272
Lon: 18.781744

Planowane rozwiązanie dla osób niewidomych obejmuje umieszczenie w tagu “ref” identyfikatora przystanku, a w tagu “local_ref” numeru przystanku.

Większość aplikacji dla niewidomych nie czytaja tagu ref ze względu na to, że często zawiera on identyfikator przystanku. Udało się natomiast przekonać dostawców nawigacji do czytania tagu local_ref jako łatwiejszy do interpretacji dla osób niewidomych. Lepiej słyszeć cyfrę niż identyfikator 6-ścio znakowy.

Tag info:
a) local_ref posiada głównie wartości jednocyfowe i jednoliterowe: https://taginfo.openstreetmap.org/keys/local_ref#values. Znaki takie jak 1, 2, A oraz 3 stanowią ponad 28% wszystkich wprowadzonych wartości w ten tag
b) ref w miastach, które sprawdzałem jest uzupełniony identyfikatorami z publicznego transportu. Zachęcam do sprawdzenia np. Łodzi lub Warszawy. W taginfo wartości takie jak 1, 2, 3, 4 stanowią około 4,5%. Szkoda, że taginfo nie da się pogrupować po ilości znaków, wtedy wiedzeilibyśmy jak często są wykorzystywane do umieszczania w te pola unikalne identyfikatory.

Moim zdaniem bardzo słusznie.

Przepraszam za spóźnione odpisywanie, dalej mam wątpliwości odnośnie Twojej zamierzonej edycji.
Planujesz wprowadzić identyfikatory które:

  • nie występują w terenie
  • nie występują na jawnie oficjalnej stronie, obecne są tylko w adresie strony

Bardziej chyba pasowałby znacznik “unsigned_ref=”

Sprawdzam Łódź: http://www.mpk.lodz.pl/rozklady/tabliczka.jsp?direction=1&lineId=899&timetableId=4775&stopNumber=370&date=2021-07-19-22:24:51 i punkt na mapie: https://www.openstreetmap.org/node/1842889142 – w Łodzi identyfikatory przystanków są 4-cyfrowe (i unikalne), nazwy przystanków nie są unikane (“Kopcińskiego - Tuwima”).

Warszawa: https://www.wtp.waw.pl/rozklady-jazdy/?wtp_dt=2021-07-19&wtp_md=8&wtp_dy=1&wtp_st=1562&wtp_pt=02: mamy unikalne nazwy “Metro Szwedzka 02” i unikalne identyfikatory “1562 02”.

W metropolii śląsko-dąbrowskiej (https://rj.metropoliaztm.pl/przystanki/bytom/) mamy nieunikalne nazwy przystanków (“Bobrek Ratusz”) z nieunikalnymi identyfikatorami 1-cyfrowymi i tak to powinniśmy nanosić na mapę.

W różnych miastach stosuje się różne sposoby identyfikacji przystanków, na OSM powinno nanosić się stan faktyczny.

Bardzo się cieszę, że przeanalizowałeś moją wypowiedź.

  1. Właśnie dzwoniłem do ZTM i te identyfikatory rzeczywiście nie występują w terenie. Natomiast każda aplikacja do nawigacji oraz ułatwiająca poruszanie się komunikacją miejską posiada te indeksy. Przykłady to:

Większość firm komunikacyjnych identyfikuje przystanki dodatkowym numerem lub literą. Jedynym znanym mi wyjątkiem jest Kraków, ale z tego co wiem to do końca roku powinny tzw. indeksy zostać dodane.
Problem jest w tym, że tych danych nie ma (jeszcze) w OSM.

  1. Występują. Wpisz dowolną trasę i zobacz wynik. Na dole strony pojawi się mapa z zaznaczonymi przystankami. Każdy przystanek ma numer np. 1, 2, 1t, 2t
    Są też na tej mapie przystanków: https://rj.metropoliaztm.pl/mapa/

Zanim przejdziemy dalej warto, wiedzieć jak działają aplikacje nawigacyjne dla niewidomych. Taka aplikacja czyta osobie niewidomej co znajduje się wokół niej oraz w jakiej odległości. Każda popularna aplikacja korzysta z map OSM. Niestety jedna aplikacja czyta tag ref, a inna nie. Korespondując z takimi firmami dowiedziałem się, że tag ref nie jest intuicyjny dla niewidomych ponieważ często znajduje się w nim długi unikalny identyfikator np. 124455. Niewidomy nie jest w stanie sobie tego nawet zapamiętać, a co dopiero sprawdzić w aplikacji z rozkładem jazdy. Poza tym tag ref jest uzupełniany w różny sposób w różnych miastach, do czego nawiązał w drugiej części swojej wypowiedzi.

Swego czasu zrobiłem analizę wybranych przystanków na całym świecie (niestety gdzieś mi się zapodziała). Wynikało z nich, że:

  1. Nazwy przystanków w większości są nieunikatowe
  2. Tag local_ref występuje rzadko, ale jak już się pojawia to zawiera łatwy do zapamiętania numer
  3. Tag ref występuje dość często w Polsce, a rzadko za granicą i zawiera głównie unikalny identyfikator przystanku

Producenci aplikacji zgodzili się na następujące działanie aplikacji:

  1. Jeżeli występuje tag local_ref to czytaj nazwę przystanku oraz zawartość tagu local_ref
  2. Jeżeli tag local_ref nie występuje to czytaj tylko nazwę przystanku
    Tagu ref aplikacje nie czytają.

W Łodzi sytuacja jest nietypowa ponieważ identyfikator przystanku jest jednocześnie jesgo indeksem.
Tutaj uważam, że powinno się skopiować tag ref do tagu local_ref.

W Warszawie tag local_ref jest zbędny ponieważ tam jest konwencja umieszczania indeksów w nazwach. Szkoda, że nie jest to ogólnopolski standard.

Te identyfikatory nanieśliśmy wspólnie z harcerzami, na wybranych liniach, w 2019. Niestety pomysł spotkał się z oporem społeczności OSM i od tamtej pory próbuję ustalić standard, który jest uniwersalny i ułatwi nawigację osobom niewidomym i jednocześnie nie popsuje nic w mapach. Zachęcam do przeczytania tego forum od początku.

Docelowo na Śląsku planujemy w tagu ref wprowadzić unikalny identyfikator ZTM, a w tagu local_ref indeks przystanku.

Myślę, że możemy się zgodzić co do kwestii, że OSM nie posiada najbardziej aktualnych danych. Stan faktyczny przystanków jest w posiadaniu przedsiębiorstw komunikacyjnych. My aktualizujemy mapy OSM dodając do istniejących przystanków dodatkowe tagi, usuwając przystanki nieistniejące i dodając brakujące.
Oba systemy będą połączone za pomocą tagu ref, czyli identyfikatora, dzięki czemu w przyszłości będzie możliwe automatyczne usunięcie nieużywanego przystanku, dodanie nowego lub aktualizacja nazwy.

Nawet na wydrukowanych rozkładach jazdy wywieszonych na przystanku?

To by było tagowanie pod render. Ale wobec ignorowania przez twórców aplikacji tagu ref trudno to inaczej rozwiązać.

Informacja z pierwszej ręki. W gablotach na rozkładach jazdy są numery przystanków, czyli te 1, 2, 1t itd.
Numery są w większości miejsc, ale są podobno gminy przejęte przez ZTM, gdzie te numery są sukcesywnie dodawane, a stare rozkłady wymieniane.
Również słupki są wymieniane na nowy typ, który posiada widoczny z daleka numer przystanku. Więcej można o tym planie przeczytać pod linkiem: https://www.metropoliaztm.pl/pl/s/nowy-wzor-informacji-przystankowej-bedzie-bardziej-czytelna-i-widoczna-z-daleka

Może się też okazać, że gdzieś są jakieś dodatkowe identyfikatory i będziemy mogli je dodać wg. przyjętej nomenklatury.
Wszystko się wyjaśni jak zaczniemy rozmawiać z MPK-Łódź i Twórcami map w Łodzi.

Nieporozumienie! Miałem na myśli identyfikatory 5-znakowe! Identyfikatory znajdujące się na tablicach zostały już w większości wprowadzone do OSM w znaczniku ref=.

W Poznaniu jest podobnie: https://www.openstreetmap.org/node/1547245756 trzy przystanki o tej samej nazwie, różniące się tylko znacznikiem ref=, który również jest długi.
Problemem nie są znaczniki na OSM, tylko działanie tych aplikacji. Czy są to aplikacje działające tylko na terenie Polski? Może aplikacje te powinny dla wybranych sieci (network=) czytać (bądź nie czytać) zawartości znacznika ref=?

Dokładnie 6-ścio znakowe. Przykład: https://www.openstreetmap.org/node/1568958010

Niestety te identyfikatory zostały wprowadzone tylko dla kilku głównych linii na Śląsku. Wiele przystanków nie ma uzupełnionego tagu ref.

Strona taginfo dla tagu ref oraz local_ref jasno wskazuje, że tag ref powinien być stosowany dla unikalnych identyfikatorów, a tag local_ref dla prostych nazw. Napisałem o tym więcej w tym poście.

To rzeczywiście jest problem. Widać, że zarówno Poznań jak i Łódź mają połączone proste nazwy z identyfikatorami.
Na chwilę obecną przychodzi mi tylko skopiowanie tych identyfikatorów z tagu ref do local_ref.
Jeżeli miałby zostać zastosowany warunek z tagiem network to musiałby zostać zaakceptowany przez społeczność, a jego zastosowanie powinno być uniwersalne na całym świecie.

Aplikacje dla niewidomych są międzynarodowe. Np. aplikacja Lazarillo powszechnie używana w Polsce pochodzi z Chile, a DotWalker z Czech.
Rozwiązanie docelowe musi być uniwersalne.

Producenci aplikacji Seeing Assistant Move niestety nie zgodzili się na czytanie tagu ref, ze względu na to, że w każdym mieście jest w nim inna wartość. Ich aplikacja jest bardzo popularna np. w Chinach mimo, że centrala firmy jest w Polsce.

Ps. Na horyzoncie natomiast widać kolejny problem, gdy jeden przystanek może należeć do wielu linii autobusowych/tramwajowych.

Trzeba do tego podejść kreatywnie - kopiować, ale tylko 2 ostatnie znaki z ref.

Mi się pomysł podoba, ale myślę, że społeczność poznańska powinna się wypowiedzieć.

Kończymy pracę nad oprogramowaniem, które umożliwi przesyłanie danych z systemu ZTM do OSM (chodzi głównie o wspomniane tagi name, ref oraz local_ref).

Obecnie pracujemy nad funkcją umożliwiającą automatyczne wysłanie zaktualizowanych danych wprost do OSM.
Proszę Was o podpowiedź, czy lepiej będzie:

  • wysyłać dane na jedno konto OSM dedykowane dla aplikacji? (aplikacja będzie miała swoje konto w systemie OSM)
  • podawać swoje dane do logowania do OSM w naszej aplikacji i wtedy plik osmchange.osc będzie wysyłany bezpośrednio z konta użytkownika? (dane logowania do OSM nie będą zapisywane w naszym systemie)
    Do uploadu danych wykorzystujemy skrypt upload.py

Ps. Jeżeli jesteście zainteresowani korzystaniem z aplikacji to dajcie znać tutaj na forum lub przez forumlarz na stronie https://rozwiazaniadlaniewidomych.org/kontakt/

Planowana data premiery to koniec stycznia 2022.

Możesz podlinkować stronę na OSM Wiki opisującą ten import i/lub automatyczną edycję?

patrz https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct https://wiki.openstreetmap.org/wiki/Import/Guidelines