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
Czytałem te dokumenty wielokrotnie. Wg. mnie one dotyczą importów danych z zewnętrznego źródła do systemu OSM.
Gdybym np. wgrywał do OSM przystanki z systemu ZTM uważam, że dokument z importem powinien powstać.
Nasze oprogramowanie pozwala wyświetlić na mapie przystankie ZTM oraz OSM i połączyć je w graficzny sposób.
Więcej informacji w tym filmie: https://youtu.be/bJpNcOIJsWo
Następnie wykonując eksport danych z naszego systemu do systemu OSM, z przystanków ZTM zostaną dodane lub zaktualizowane dane w przystankach OSM takie jak name, ref oraz local_ref.
W tej wersji żadne nowe obiekty nie będą dodawane do OSM.
Każdy użytkownik przed wykonaniem eksportu danych z naszego systemu do OSM (importu do OSM) będzie mógł podejrzeć plik osmchange.osc oraz zobaczyć jakie zmiany zostaną wprowadzone do OSM - podobnie jak w iD, chociaż na razie w bardziej prymitywny sposób.
Naszej aplikacji jest bliżej do JOSMa niż do tradycyjnego importu danych ponieważ to użytkownik decyduje kiedy i jakie dane wysłać do systemu OSM.
Czy powinienem tworzyc dokumentacje importu?
Strona wiki projektu: https://wiki.openstreetmap.org/wiki/OsmIntegrator
Lepiej wysyłać dane z kont użytkowników - dostaną np. informację o dyskusji pod ich zestawem zmian.
Niezależnie od tego, czy potraktujemy to działanie jako import, czy jako edycję, fajnie by było, gdyby na wiki był opis procedury. A najlepiej, gdyby w opisie zmiany był m.in. odsyłacz do tej strony na wiki.
Brzmi ok.
Dodamy jedno i drugie.
Wiki z planem importu została dodana pod tym linkiem: https://wiki.openstreetmap.org/wiki/Automated_edits/luktar/OsmIntegrator_-_fixing_stop_signs_for_blind
Przykładowy import obejmuje obszar Żor, na którym występuje dokładnie 7 przystanków ZTM.
Nie uważam, żeby to był dosłowny import, więc nie dodałem wpisu w Import/Catalogue.
Czy powinienem to zrobić?
Czy powinienem dodawać tag bot=yes do changesetu skoro zmiany będą zatwierdzane przez użytkownika?
To jest ewidentny import.
Już działa.
To jest wczesna wersja i nie wszystko działa tak jak trzeba.
Dlatego jeszcze nie informowałem oficjalnie o jej istnieniu.
Jeżeli jesteście zainteresowani skorzystaniem z aplikacji i edycją obszaru to zachęcam do założenia użytkownika i przeczytania instrukcji obsługi (w instrukcji są linki do wersji wideo).
Na początku lutego wyjdzie wersja, która pozwoli na pobieranie aktualnych danych z systemu OSM.
Obecnie bazujemy na danych z początku października 2021.
Ok. Mateusz uważasz, że ten rozdział (kategoria) w katalogu będzie ok - “Ongoing Imports, Semi-Automated”?
Zauważyłem dzisiaj, że przystanki na Śląsku mają zazwyczaj highway=bus_stop na węźle public_transport=stop_position.
Czy to nie jest błąd? Wg mnie highway=bus_stop powinien być połączony z public_transport=platform. Chyba nawet kilka validatorów krzyczy, że bus_stop nie powinien być częścią trasy.
Taginfo (PL) mówi, że wygrywa platform: 48594, kontra stop_position: 22345
Błąd, tzn. dobrze, że w ogóle są zaznaczone, ale bardziej poprawnie byłoby umieszczać highway=bus_stop w miejscu oczekiwania podróżnych. Tu krótka dyskusja (i było takich więcej) o tym błędzie: https://www.openstreetmap.org/changeset/94456044.
Czy kwestia “wielu przystanków w 1” została już ustalona?
Pytam o to bardziej w kontekście aktualizacji wiki, bo to jest coś co by się przydało i ogólnie standaryzowania tego problemu z przystankami w OSMie.
Z tego co widziałem i pytałem też na Discordzie, nie ma na to jasno ustalonego sposobu, ale można parę komentarzy znaleźć, że ludzie mapują jako:
-
Dodawanie kolejnych punktów “highway=bus_stop public_transport=platform”, a “public_transport=stop_position bus=yes” ma tylko te niezbędne tagi bez żadnych nazw i refów.
-
Trzymanie tego w jednym węźle/obszarze i obsługiwanie przez sufiksy/namespace’y.
-
Niektórzy dodają też alt_name, ale jak dla mnie, to rozwiązanie powoduje jeszcze więcej problemów.
-
Ma tę zaletę, bo nie powoduje to wysypu mnóstwa tagów z sufiksami operatorów. Nie pozwala za to utrzymywać przystanku jako obszar i duplikuje węzły. Nie ma to sensu w tworzeniu relacji, bo nie widać, czy dana sieć przystanku współdzieli ten sam przystanek z inną, nie mówiąc już o potencjalnym sensowym wykorzystywaniu danych do routingu z użyciem transportu publicznego.
-
Opcja wymaga dla mnie doprecyzowania, opisania na wiki, żeby móc z tego zacząć korzystać masowo.
Maro wskazał jedno z ref:xxx, drugie bez ref:xxx, ale czy to nie będzie wywoływać jakichś lokalnych konfliktów i będzie “walka” o to, który jest ważniejszy?
Podejrzewam, że przy importach, może to mieć też kluczowe znaczenie i może być łatwiej jednak trzymać wszystko pod swoimi xxx. Nie narzucam żadnego z tych, ale bardziej to jako pytanie, bo obie wersje mi się podobają jeśli chodzi o standaryzowanie tego w ten sposób.
I odnośnie 2, bo do tego powoli zmierzam. Wspomniane zostało o ref:xxx, ale jak chcemy iść w tym kierunku, to więcej tagów przystankowych powinno dostać swoje :xxxx, albo powinno to zostać rozwiązane w inny sposób (nie mam pomysłu jaki?). Jako przykład rozważmy 1 fizyczny przystanek, który jest używany przez 3 różnych przewoźników i żeby było ciekawiej, to każdy z nich posiada swój słupek i swoją własną nazwę z innym local_ref.
To jest powód dla którego bardzo chciałbym, żeby zostało to ustandaryzowane.
Załóżmy mamy sieci/operatorów/przewoźników a, b, c? To też musi zostać ustalone, co przyjmujemy za te xxx i najlepiej, żeby ta wartość zawierała się w 1 z tagów, czy to operator, network, bądź innym:
highway=bus_stop
public_transport=platform
name:a=Nazwa przystanku operatora a
name:b=Nazwa przystanku operatora b
name:c=Nazwa przystanku operatora c
ref:a=id_a
ref:b=id_b
ref:c=id_c
local_ref:a=local_ref_a
local_ref:b=local_ref_b
local_ref:c=local_ref_c
operator?
network?
Tagi operator, network w teorii mogą zawierać wiele wartości np. oddzielane “;”, bo na ten moment nie widzę z tym problemu jeśli chodzi o przetwarzanie tych informacji.
Czyli np.:
operator=a;b;c
network=network a; network b; network c
W przypadku name, ref i local_ref istotne już jest do którego operatora/sieci należą, bo oddzielanie ich “;” z powoduje utratę przypisania do odpowiednich linii.
Jak to wygląda aktualnie w tym oprogramowaniu, które podesłałeś i co sądzicie o ustandaryzowaniu tagowania przystanków w taki sposób?