Komunikacja miejska dla niewidomych na terenie Śląska

To moją wskazówką jest nieużywanie OSM. Tj. używanie jako warstwy bazowej, ale same informacje o przystankach i liniach trzymać w oddzielnej “bazie”. Czemu? Chociażby z powodu tych problemów, o których napisałeś. Zawsze się znajdzie ktoś komu będzie przeszkadzała nazwa przystanku, czy jego położenie. Moim zdaniem fraza, że coś jest “do ustalenia na forum” to jakiś żart (nikogo nie obrażając) - pomijając, że nie każdy korzysta z forum, to nie każdy będzie takie ustalenie respektował albo po ludzku o tych ustaleniach pamiętał.

Masz niezależny zbiór danych, tj. przystanki z ZTM, możesz z nim robić co chcesz. Wpisywanie się z nim w konwencję OSM to źródło frustracji i strata czasu. Ale jak faktycznie nie ma wyboru (bo aplikacje korzystają w pełni z OSM) to faktycznie, to wszystko jest “do ustalenia na forum” :wink: Ale wtedy na pewno nie daj się wciągnąć w odczytywanie czegoś “z relacji”. Biorąc pod uwagę jak łatwo je popsuć, to nie ryzykowałbym opierania na nich czegokolwiek.

Dzięki za odpowiedzi i sugestie.

Program DotWalker czyta ref i taki ciąg znaków będzie denerwujący dla niewidomego.
Wolałbym, żeby rozwiązanie było maksymalnie proste. Indeks w nazwie przystanku byłby idealny.
Indeks stosowany na poznańskich przystankach też jest ok (skrót nazwy + numer).
Właśnie skontaktowałem się z jedną z firm tworzących rozwiązanie nawigujące dla niewiodmych i zapytałem o możliwość czytania “ref” przez ich aplikację. Natomiast nie jest to domyślne rozwiązanie przez co refy nie zawsze się sprawdzają.

Od ZTM dostaliśmy listę wszystkich przystanków i tak na przykład dla “Dąbrowa Górnicza Centrum” mamy takie informacje:

Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	1	9	linie: 28,49,140,175,603,605,606,637,928	50.325388	19.187766
Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	2	15	linie: 28,49,84,116,140,175,260,603,605,606,634,635,637,928,984	50.325039	19.187831
Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	3	20	linie: 18,27,55,84,116,182,260,604,634,635,690,801,807,808,811,814,831,902N,903N,984	50.325279	19.188142
Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	4	12	linie: 18,27,55,644,690,801,807,808,811,814,831,904N	50.32495	19.188303
Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	1t	3	linie: 21,22,28	50.325399	19.187193
Dąbrowa Górnicza	Dąbrowa Górnicza Centrum	2t	3	linie: 21,22,28	50.325546	19.185584

Tutaj pytanie - czy to jest możliwe oraz jak to zrobić, aby nikt nie mógł popsuć rozwiązania?

Na śląsku to w ogóle nie wygląda. Udało nam się zmodyfikować przystanki na kilku liniach. Docelowo chicielibyśmy opisać wszystkie przystanki ZTM najlepiej automatycznie.

Poznańskie rozwiązanie bardzo mi się podoba. Weźmiemy pod uwagę ten sposób oznaczania platform.

Jango, czy mógłbyś rozwinąć ten temat. Nie wydaje mi się, żeby programy dla niewidomych korzystały z dodatkowych warstw. Jak możemy to sprawdzić?

Po pierwsze żeby wgrać przystanki z waszej bazy danych trzeba by pierw usunąć stare, inaczej zostaną zdublowane, co za tym idzie stare przystanki są powiązane z relacjami czyli trasami autobusów itd.
Stare przystanki są powiązane z drogami, torami.
Chcesz mi powiedzieć że to dobry pomysł zniszczyć wszystkie relacje tylko po to by dać im ref w nazwie który nie jest zgodny z dokumentacją ani konwencją?
Nie możesz zablokować danych na edycję.
Każdy może edytować i nie zabronisz nikomu wprowadzać poprawnych danych.

Jeszcze dodam że już namieszaliście dodając ref z kosmosu na niektórych przystankach. A jak będę mieć więcej czasu będzie trzeba przejrzeć tramwaje bo tam już całkiem zrobiliście siekę, a robione było ręcznie a nie z automatu. Teraz sobie można wyobrazić co będzie jak pójdzie automat.

Chyba nie zdajecie sobie sprawy ile danych trzeba by naprawić przy wgraniu tych przystanków na nowo, pytanie jeszcze jakiej jakości jest ta baza? :x

Przykład tego co już zrobiliście! :smiley:

https://www.openstreetmap.org/#map=19/50.25760/19.03650&layers=N

Nie dodajemy ref., również nie usuwamy przystanków, nie mamy zamiaru ich usuwać, nie niszczymy relacji. Nie wiem w ogóle skąd te pomysły.
Konwencja dla komunikacji na terenie Polski jest taka:

Źródło: https://wiki.openstreetmap.org/wiki/WikiProject_Poland/Komunikacja_publiczna

Dodajemy do nazw przystanków numer, który jest pobrany z wiarygodnego źródła, czyli ze strony https://metropoliaztm.pl.

W naszą pracę zaangażował się Związek Harcerstwa Polskiego oraz ZTM.
Cofając zmiany, które wprowadziliśmy usuwasz nie tylko naszą pracę, ale przede wszystkim drogowskazy jakie stworzyliśmy specjalnie dla osób niewidomych.
Wczoraj miałem telefon od niewidomego, któremu “ktoś” usunął numery przystanków na trasie do domu (okolice Chorzów Wesołe Miasteczko). Dobra robota.

Czy kiedykolwiek wyobraziłeś sobie jak to jest niewidzieć?
Takie aplikacje jak Seeing Assistant Move lub DotWalker są dla osób niewidomych jedynym drogowskazem, informacją czy zmierzają we właściwym kierunku szczególnie w miejscach, których nie znają. To ogromne ułatwienie, którego osoby nie mające takich problemów nie doceniają.

Napisałem na tym forum post ponieważ wierzę, że znajdzie się tu kompetentna osoba, która pomoże nam rozwiązać problem.

Z Tobą olo81 już dyskutowaliśmy wspólnie w komentarzu do naszych poprawek i nic z tej rozmowy nie wyniknęło. Podobnie jak w poprzednim i w tym przypadku oskarżasz nas o wszelkie zło, a nie zastanowiłeś się kompletnie jakie korzyści dostarczamy.
Zaproponowałem Ci kontakt telefoniczny, oraz rozmowę na czacie, ale nie skorzystałeś z tych opcji.

Nie szukam tutaj powodów do sporów. Staram się wypracować rozwiązanie, które zarówno przyniesie korzyści osobom niewidomym jak i będzie zgodne ze standardem OSM. Więc jak masz dobry pomysł to zapraszam do dyskusji, a jak szukasz powodów do kłótni to zrób to gdzie indziej.

DotWalkier importuje dane z plików .osm. Można więc je przed importem zmienić, dopisując indeks do nazw przystanków.
http://www.dotwalkerpro.com/dw/dotwalker_en.html#p9

Seeing Assistant Move też czyta dane osm: http://seeingassistant.tt.com.pl/pl/move/tutorial/#loading oraz wiele innych formatów, w tym tekstowy Loadstone.

Indeks w osobnym tagu (platform_index,name_index,…) i dopisywanie go do name przed konwersją do docelowego formatu.

Na znaku drogowym jest napisane: {nazwa miasta}, {nazwa przystanku}; a tabliczka wygląda tak:

Numer stanowiska nie wygląda jakby był częścią nazwy przystanku. 6-cyfrowe kody w adresach stron są w użyciu tylko na ich stronie, nie ma ich fizycznie na tabliczkach. Poza tym co z takim przystankiem: “Ochojec Jaworowa dwa dwa”, czy raczej “Ochojec Jaworowa dwa stanowisko drugie”?

Od kilku dni dodaję odnośniki do rozkładów jazdy (klikając w programie OsmAnd na przystanek będzie można szybko przejść do strony z rozkładem), opisuję stanowiska i łączę przystanki z chodnikami (aby tworzyły sieć dróg). Nie wyobrażam sobie, aby dało się to zrobić w sposób automatyczny.

Po naprawieniu wszystkich przystanków - co oznacza mnóstwo pracy - w samych Katowicach jest ich 346 - trzeba będzie naprawić relacje linii. Przykładowo tutaj relacje linii autobusowych przebiegają przez przystanki po obu stronach drogi, istnieje tutaj linia T16, która już tędy nie przebiega. Nie ma już podziału na MZK Tychy i KZK GOP - tworzą one teraz jedną sieć.

Czy są jakieś zastrzeżenia do moich edycji (przykład)?

  1. highway=bus_stop może być tylko na węźle - taka wersja na linii działać nie będzie.
    https://www.openstreetmap.org/way/677301384

  2. Dwa różne obiekty z identycznym zestawem tagów, w tym z identycznym refem.
    https://www.openstreetmap.org/way/203938625
    https://www.openstreetmap.org/way/203938610

Rzeczywiście, będę miał co poprawiać! Wersja deweloperska edytora iD stosuje już poprawne znaczniki: “bus=yes; highway=footway; public_transport=platform”.

Nie widzę sprzeczności - “ref” oznacza numer stanowiska, przystanki te są w osobnych relacjach “Dąb Huta Baildon” i “Dąb Silesia City Center”.

Co ze znacznikiem “highway=bus_stop” - powinien być on na jezdni, czy usunąć go, a miejsce zatrzymania oznaczać tylko jako “bus=yes; public_transport=stop_position”?

Ale to nie jest ref. Jedną z cech refa jest właśnie to, że można uniknąć tworzenia relacji, gdyż ref łączy obiekty. Tutaj to nie działa, bo to jest indeks w ramach relacji.

szydzio już tutaj na to odpowiedział.

Powiedzcie co o tym myślicie.

Zrobiłem analizę opisu przystanków w 16 miastach w Polsce i na Świecie.
https://docs.google.com/document/d/1Vr5LPIbwtKrn6rXasoE8kSfmBbT5QwElDAky9ngj2Eo/edit?usp=sharing

Podsumowanie jest następujące:

Analizie zostało poddane 15 miast w tym 7 polskich i 8 zagranicznych.
Indeks w nazwie przystanku ma tylko jedno miasto - Warszawa.
Numery referencyjne numeryczne używa 7 miast.
Numerów referencyjnych nie używa 7 miast.
Jedno miasto korzysta z numerów referencyjnych złożonych z liter i cyfr - Poznań.
Tag public_transport=stop_position używa 13 miast.
Tag bus=yes używa 12 miast.
Tag highway=bus_stop używa 10 miast.

Wniosek:

Przystanki autobusowe w mieście powinny być docelowo opisane w następujący sposób:

  • Nazwa przystanku bez indeksu
  • Numer referencyjny numeryczny
  • Tagi:
public_transport=stop_position
bus=yes

Czy taki standard mógłby zostać zastosowany dla wszystkich przystanków w ZTM na Śląsku?
Czy zmiana wszystkich ref’ów na 6-ścio znakowe indeksy ZTM będzie z czymś kolidować?

maraf24 napisał:

Czy taka konwersja mogła by się dziać automatycznie bez wprowadzania zmian w programach docelowych (Move, DotWalker itd)?
Gdzie mogę znaleźć więcej informacji na ten temat?

Ps. Jak robicie żeby:

  1. Dodać url do ładnej nazwy np. kliknij tutaj?
  2. Określić w cytacie nazwę osoby cytowanej?

Verdizulo napisał:

Url przystanku składa się z dwóch części:
baza=“https://rj.metropoliaztm.pl/rozklady/przystanek/
identyfikator=159586

Jeżeli uda mi się pozyskać identyfikatory dla przystanków z ZTM to wystarczy jak się je wpisze w pole “ref”. Tag “url” będzie można automatycznie wypełnić poprzez złożenie “bazy” z identyfikatorem (refem). Dzięki temu przy ewentualnej zmianie nazwy strony internetowej ZTM linki będzie można łatwo poprawić.

Myślę, że jeżeli będziemy mieli przystanki powiązane za pomocą unikatowego identyfikatora z bazą danych ZTM to będzie można bardzo łatwo dokonywać różnego typu automatycznych aktualizacji np. zmiana pozycji, nazwy, url, indeksu, przeniesienie na czas remontu itd.

Ja bym używał też tagu highway=bus_stop (nie jestem fanem public_transport=stop_position, autorom tego systemu tagowania udało zwiększyć się poziom skomplikowania bez dodawania zauważalnych zalet)

Te tagi opisują miejsce zatrzymania się pojazdu, a za przystanek, jak zauważyłem, zawsze uważa się miejsce, w którym ludzie czekają na pojazd/jest wiata/słupek.
To jest tag public_transport=platform.

Dodatkowo ciągle jest w użyciu tag highway=bus_stop i nic nie wskazuje, by został w najbliższym czasie odesłany w niebyt.
Prawidłowo otagowany przystanek powinien zawierać oba te tagi - public_transport=platform i highway=bus_stop, niekoniecznie na jednym obiekcie.

Oczywiście, że konwersja musi być automatyczna, więc będzie robił to program, a nie człowiek.

Z tego co wiem to jeszcze np. Lublin - tam w name jest indeks a częściowo to nawet to co gdzie indziej jest w ref - przykład.

(nawias kwadratowy otwierający)url=adres url(nawias kwadratowy zamykający) kliknij tutaj? (nawias kwadratowy otwierający)/url(nawias kwadratowy zamykający)

(nawias kwadratowy otwierający)quote=nick(nawias kwadratowy zamykający)cytat z innej osoby (nawias kwadratowy otwierający)/quote(nawias kwadratowy zamykający)

Najprościej zaznaczyć cytowany kawałek i kliknąć “Quick quote” (lub polski odpowiednik) pod postem, z którego cytujesz. Wtedy forum samo Ci zrobi to, co szydzio ładnie opisał.

Prawdopodobnie nie jesteście jedyną taką grupą. Może warto urządzić akcję uzgadniania z twórcami oprogramowania wspólnego rozwiązania, które mogłoby korzystać z OSM (nie widzę możliwości ogólnego rozwiązania przez dodatkową warstwę, jak proponowal janog - to jest dobre rozwiązanie, kiedy się samemu pisze program, który z tego korzysta) i nie naruszało dotychczasowych danych, dzięki czemu nie będą one “poprawiane” przez inych użytkowników?

Technicznie to dość proste, potrzebny jest schemat tagowania wspólny dla aplikacji (dlatego trzeba go uzgodnić przynajmniej z twórcami najczęściej używanych aplikacji, reszta się po jakimś czasie dostosuje, albo ich aplikacje przestaną być używane :wink: ), np “blind:”. I tak, jeśli obiekt będzie mieć tag “blind:name=jakaś nazwa przystanku z numerem” , to użyje go zamiast “name=jakaś nazwa przystanku bez numeru” i możecie dawać nazwy pod kątem niewidomych, i nikt Wam ich nie będzie poprawiać (chyba że skasuje obiekt, utworzy od nowa i zapomni o tym tagu, ale z tym trzeba żyć i pilnować).

EDIT: taginfo twierdzi, że ktoś już w tę stronę kombinował dla niesłyszących. Aż dziwne, że nic nie znalazłem o niewidomych.

Przepraszam, nie doprecyzowałem pytania. Chodziło mi o to, czy taka konwersja mogła by być wykonywana jeszcze przez serwer openstreetmap przed pobraniem danych do aplikacji. W innym przypadku będzie wymagana zmiana kodu źródłowego programu.
Z doświadczenia wiem, że modyfikacja aplikacji działających w kilku(nastu) krajach jest bardzo trudna (ale nie niemożliwa).

Zauważyłem, że w niektórych miastach się stosuje taką konwencję (Warszwa, Wrocław), a w niektórych nie (Katowice, Gdańsk).
Wniosek jest taki, że w przypadku poprawnej implementacji miejsce zatrzymania się autobusu powinno mieć tagi:

public_transport=stop_position
bus=yes
highway=bus_stop

a miejsce gdzie można poczekać na autobus:

public_transport=platform
bus=yes
highway=bus_stop

Czy dobrze myślę?

To rozwiązanie mi się bardzo podoba. Twórcy aplkacji musieli by dodać tylko funcję: “jeżeli pole blind:name jest puste czytaj pole name, inaczej czytaj pole blind:name”.
Mam dwa pytania:

  1. W jaki sposób uzgodnić standard?
  2. Do czego służy dwukropek w nazwie blind:name?

Dodatkowo brak miejsc zatrzymania autobusu (public_transport=stop_position).
Wbrew pozorom dla niewidomych taki standard jest korzystny.

Dzięki rmikke i szydzio za pomoc z cytatami i linkami :).

Bez highway=bus_stop.

Bez bus=yes.

I do tego stop_area.

Ja bym zaczął od napisania do twórców aplikacji i innych podobnych do Waszych grup, że macie taki pomysł i co oni na to i co by jeszcze warto w ten sposób rozwiązywać. W tym momencie można już zacząć te tagi wprowadzać i poczekać aż choć jedna większa aplikacja zacznie ich używać. To ważne, bo przy ustalaniu tego schematu na wiki na mur-beton padnie “ale przecież tego nikt nie wprowadza, ani nie używa”.

Następnie pisze się to jako propozycję na wiki (angielskim), wrzuca się info na listę tagging, czyta się dyskusję i ewentualnie modyfikuje propozycję, po czym robi się głosowanie pod propozycją… i w zasadzie już, jest nowy standard.

Taki jest przyjęty w OSM sposób oznaczania pewnego schematu, takiej przestrzeni nazw. Łatwiej jest rozszerzać schemat o konkretnym przeznaczeniu, niż wymyślać i wprowadzać nowe, niepowiązane w żaden widoczny sposób (mimo że logicznie to SĄ powiązane) tagi. Czyli pokazuje się w ten sposób związki między tagami. Porządek się zaprowadza. Ułatwia to też trochę pisanie aplikacji, wykorzystujących te tagi.

Poleca się instrukcję do BBCode (link znajdziesz zawsze pod okienkiem do pisania postów). :wink:

Konwersję będzie robił program, który do tego stworzycie. Potem udostępnicie wynik jego prac.
Podobnie jest to zrobione z danymi UMP na http://gps.zlotowicz.pl/

Coś czuję, że w tym polu nie będzie żadnych nazw tylko opisy :wink: