You are not logged in.

#26 2019-03-21 12:08:08

gscscnd
Member
From: Rybnik
Registered: 2013-08-13
Posts: 174

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Nie rozumiem do końca z tym stop_area. Na stronie jest public_transport=stop_area, które już wcześniej jest ustawione na public_transport=platform.

stop_area to relacja pozwalająca na powiązanie miejsca zatrzymania pojazdu (stop_position) z miejscem oczekiwania podróżnych (platform). Przykład: 7407180.

Offline

#27 2019-03-24 22:22:22

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

rmikke wrote:

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.

Podejrzewam, że wprowadzenie takich zmian do aplikacji może zająć trochę czasu. Poza tym twórcy mogą być niechętni do wprowadzenia tagów, które nie są standardem. Może spróbujmy opisać sytuację na angielskim forum i zrobić głosowanie - być może pomysł spotka się z aprobatą.

maraf24 wrote:

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

To proponuję blind:name="nazwa" oraz blind:description="opis".

luktar wrote:

Nie rozumiem do końca z tym stop_area. Na stronie jest public_transport=stop_area, które już wcześniej jest ustawione na public_transport=platform.

gscscnd wrote:

stop_area to relacja pozwalająca na powiązanie miejsca zatrzymania pojazdu (stop_position) z miejscem oczekiwania podróżnych (platform). Przykład: 7407180.

Czyli wszystkie miejsca zatrzymania autobusu o danej nazwie (np. AWF) oraz miejsca gdzie można na ten autobus poczekać są zgrupowane w relacje, która ma tag public_transport=stop_area.
Samo miejsce oczekiwania na autobus powinno mieć public_transport=platform. Dobrze to rozumiem?

Offline

#28 2019-03-25 08:51:56

gscscnd
Member
From: Rybnik
Registered: 2013-08-13
Posts: 174

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Czyli wszystkie miejsca zatrzymania autobusu o danej nazwie (np. AWF) oraz miejsca gdzie można na ten autobus poczekać są zgrupowane w relacje, która ma tag public_transport=stop_area.
Samo miejsce oczekiwania na autobus powinno mieć public_transport=platform. Dobrze to rozumiem?

https://wiki.openstreetmap.org/wiki/Key … 60_seconds.

Offline

#29 2019-03-25 11:13:48

rmikke
Moderator
From: Warszawa
Registered: 2014-11-14
Posts: 1,836
Website

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Podejrzewam, że wprowadzenie takich zmian do aplikacji może zająć trochę czasu. Poza tym twórcy mogą być niechętni do wprowadzenia tagów, które nie są standardem. Może spróbujmy opisać sytuację na angielskim forum i zrobić głosowanie - być może pomysł spotka się z aprobatą.

Z drugiej strony - sprawdzonym jest, społeczność niechętnie przyjmuje standardy, których nikt nigdzie nie używa.
Dlatego lepiej najpierw pomiędzy zainteresowanymi ustalić, co jest potrzebne, zacząć używać (co najmniej poustawiać trochę tych tagów), POTEM LUB RÓWNOLEGLE opisać to na wiki jako propozycję, a dyskusję i głosowanie urządzać, kiedy już taginfo będzie te tagi pokazywać w liczbie wskazującej, że ktoś tego używa.

Twórcy aplikacji prawdopodobnie o tym wiedzą.

Offline

#30 2019-03-26 19:44:26

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

gscscnd wrote:

Teraz wszystko jest jasne.

rmikke wrote:

(...) lepiej najpierw pomiędzy zainteresowanymi ustalić, co jest potrzebne, zacząć używać (co najmniej poustawiać trochę tych tagów), POTEM LUB RÓWNOLEGLE opisać to na wiki jako propozycję, a dyskusję i głosowanie urządzać, kiedy już taginfo będzie te tagi pokazywać w liczbie wskazującej, że ktoś tego używa.

Rozumiem, że aby zwiększyć ilość tagów trzeba je uzupełnić. Ja mam listę wszystkich przystanków ZTM i mógłbym spróbować automatycznie dodać ten brakujący tag do przystanków w OSM, oczywiście ze wstępną weryfikacją społeczności OSM. Pojawiają się dwa pytania:

1. Czy robiliście już takie automatyczne aktualizacje i macie dobre praktyki?
2. Najpierw planuję ściągnąć wszystkie przystanki ze Śląska z OSM i sprawdzić, czy pasują do tych z ZTM. W jakiej formie najlepiej dostarczyć listę przystanków do weryfikacji i komu?

Obecznie jestem w trakcie rozmów z dostawcami aplikacji.
Dam znać, jak będą jakieś konkrety.

Offline

#31 2019-03-27 12:32:52

Mateusz Konieczny
Member
Registered: 2013-09-22
Posts: 2,257

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Przy automatycznych edycjach w OSM https://wiki.openstreetmap.org/wiki/Aut … of_conduct jest jedną z istotnych rzeczy

Offline

#32 2020-06-30 07:44:59

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Witajcie,

Minęło trochę czasu od ostatniego posta w tym wątku. Udało mi się rozpocząć współpracę z bardzo doświadczonym programistą, który zdecydował się podjąć tego zadania.
Skontaktowałem się również z wiodącymi dystrybutorami nawigacji dla niewidomych i spotkałem się z pozytywnym odzewem jeżeli chodzi o chęć dodania mechanizmu odczytującego dodatkowy tag przeznaczony dla niewidomych.

Podsumowując naszą dyskusję, masowa modyfikacja przystanków będzie obejmowała dodanie tagu "blind:name"zawierającego nazwę przeznaczoną dla osób niewidomych (nazwa przystanku + identyfikator np. "Katowice Piotra Skargi 1", "Katowice Piotra Skargi 2" itd.)

Niestety nadal nie wiem który obiekt przystanku powinien zostać zaktualizowany (czy wszystkie). Wg. tego co zostało napisane w tym wątku oraz mojej prywatnej analizy przystanek może składać się z następujących elementów:
1. Miejsce zatrzymania pojazdu

public_transport=stop_position

2. Wiata przystanku

amenity=shalter

3. Kawałek chodnika przy przystanku

highway=footway

4. Platforma

public_transport=platform

5. Miejsce oczekiwania podróżnych

public_transport=platform

Do analizy wykorzystałem Katowice Misjonarzy Oblatów, Katowice Piotra Skargi i Rybnik Śródmieście.

Po osobistej konsultacji z przedstawicielami ZTM dowiedziałem się, że udostępniają oni w swoich bazach wyłącznie pozycję słupka przystanku, czyli podpunkt 5. Miejsce oczekiwania podróżnych. Na mapach OSM, a terenie ZTM często nie ma słupka. Czy to oznacza, że tam gdzie go nie ma powinien być dodany, a tam gdzie jest powinien zostać do niego dodany tag "blind:name"?

Słupek jest również ważny dla niewidomych, ponieważ jest bardziej wartościową pozycją niż miejsce zatrzymania pojazdu.

Jeżeli miałbym dodać słupek, to jakie tagi powinien zawierać, tak aby mógł być wykorzystany w późniejszych aktualizacjach dla innych miast?

Offline

#33 2020-06-30 10:07:49

Mateusz Konieczny
Member
Registered: 2013-09-22
Posts: 2,257

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Wg. tego co zostało napisane w tym wątku oraz mojej prywatnej analizy przystanek może składać się z następujących elementów:
1. Miejsce zatrzymania pojazdu

public_transport=stop_position

2. Wiata przystanku

amenity=shalter

3. Kawałek chodnika przy przystanku

highway=footway

4. Platforma

public_transport=platform

5. Miejsce oczekiwania podróżnych

public_transport=platform

Pominłęłeś najważniejszy tag - highway=bus_stop (na przystanku autobusowym) (razem z 5/4) czy railway=tram_stop (na tramwajowym) (razem z (1))

(tagi public_transport są w zasadzie zbędne i można je pominąć bez jakiejkolwiek straty)

A 2 to amenity=shelter, nie amenity=shalter

luktar wrote:

nazwa przystanku + identyfikator np. "Katowice Piotra Skargi 1", "Katowice Piotra Skargi 2" itd.

Jeśli nazwa ta jest na tabliczce z nazwą przystanku to chyba może do name to trafić?

Jeśli nie jest - to czy numer nie pasuje czasem do tagu ref?

Na mapach OSM, a terenie ZTM często nie ma słupka.

Jesteś pewien? Np https://www.openstreetmap.org/#map=19/50.09736/18.55039 ma highway=bus_stop w miejscu oczekiwania podróżnych/słupka i jest to typwe mapowanie.

https://www.openstreetmap.org/#map=19/50.26198/19.01809 ma błędnie zaznaczone highway=bus_stop - na jezdni

Last edited by Mateusz Konieczny (2020-06-30 10:12:24)

Offline

#34 2020-06-30 16:18:15

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Mateusz Konieczny wrote:

Pominłęłeś najważniejszy tag - highway=bus_stop (na przystanku autobusowym) (razem z 5/4) czy railway=tram_stop (na tramwajowym) (razem z (1))
(tagi public_transport są w zasadzie zbędne i można je pominąć bez jakiejkolwiek straty)

Ja nie planuję ingerować w istniejące tagi. Umieściłem w swojej notatce te, którymi się różnią poszczególne obiekty.

Planuję jedynie dodać tag "blind:name" do wybranego obiektu, najlepiej słupka (miejsca oczekiwania podróżnych) lub dodać słupek z tagiem, gdy słupek nie istnieje.

Mateusz Konieczny wrote:

Jeśli nazwa ta jest na tabliczce z nazwą przystanku to chyba może do name to trafić?

Niestety nie ma identyfikatora. W Warszawie jest, na Śląsku nie.

Mateusz Konieczny wrote:

Jeśli nie jest - to czy numer nie pasuje czasem do tagu ref?

"Refy" nie są honorowane przez wszystkich dostawców aplikacji dla niewidomych. Jedni ich używają (DotWalker) inni nie (Lazarillo, Seeing Assitant Move) i nie zamierzają. Mam to potwierdzone korespondencją.

Mateusz Konieczny wrote:

Jesteś pewien? Np https://www.openstreetmap.org/#map=19/50.09736/18.55039 ma highway=bus_stop w miejscu oczekiwania podróżnych/słupka i jest to typwe mapowanie.

Rybnik faktycznie ma miejsca postojowe dla oczekujących - wielki plus dla osób tworzących te mapy. Natomiast Rybnik należy do ZTZ, nie ZTM. Katowice i okolice nie mają takich słupków w OSM.

Mateusz Konieczny wrote:

https://www.openstreetmap.org/#map=19/50.26198/19.01809 ma błędnie zaznaczone highway=bus_stop - na jezdni

Dlatego chcemy dodać taki słupek, lub jak jest błędnie umieszczony, to poprawić jego pozycję na podstawie wytycznych z ZTM.

Czy uważacie, że automatyczne dodanie do słupków tagu "blind:name", dodanie słupków jeżeli nie istnieją lub poprawa ich pozycji gdy jest błędna to dobra droga?

Offline

#35 2020-06-30 22:35:35

rmikke
Moderator
From: Warszawa
Registered: 2014-11-14
Posts: 1,836
Website

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Czy uważacie, że automatyczne dodanie do słupków tagu "blind:name", dodanie słupków jeżeli nie istnieją lub poprawa ich pozycji gdy jest błędna to dobra droga?

"Słupek nie istnieje" w sensie że jest w terenie, a brak w OSM?
Bo jakoś nie mam pewności...

Offline

#36 2020-07-01 07:27:43

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Czy uważacie, że automatyczne dodanie do słupków tagu "blind:name", dodanie słupków jeżeli nie istnieją lub poprawa ich pozycji gdy jest błędna to dobra droga?

rmikke wrote:

"Słupek nie istnieje" w sensie że jest w terenie, a brak w OSM?
Bo jakoś nie mam pewności...

Dokładnie tak.

Przykładowe pozycje słupków ZTM dla przystanku Piotra Skargi:

Katowice	Katowice Piotra Skargi	2	50.261809	19.018798
Katowice	Katowice Piotra Skargi	3	50.261939	19.018476
Katowice	Katowice Piotra Skargi	4	50.262097	19.018154

Przykłady:

Brak słupków:

1. Aglomeracja Śląska
Katowice Piotra Skargi
Bytom Dworzec - 12 przystanków, tylko miejsca postojowe autobusów
Katowice Rondo - 2 duże platformy
Chorzów rynek

2. Poznań
Poznań Uniwersytet Ekonomiczny
Poznań Główny

3. Warszawa
Warszawa Centrum 03

Wniosek jest taki, że w miastach, gdzie nie ma słupków dominują:
- miejsce zatrzymania autobusu
- platforma lub fragment ścieżki dla pieszych
- ewentualnie wiata

Są słupki:

1. Rybnik
Rybnik Tadeusza Kościuszki

2. Wrocław
Wrocław Dworcowa
Wrocław Komuny Paryskiej

3. Kraków
Muzeum Armii Krajowej N/Ż

Słupki w tych trzech lokacjach mają wspólne tagi:
- bus=yes
- highway=bus_stop
- public_transport=platform

Pytanie, czy dodanie 6500 słupków, jeżeli nie istnieją lub dodanie tagu do istniejących słupków, w obszarze ZTM z niczym nie koliduje i jest zgodne z ogólnie przyjętą konwencją?

Ps. Formalnie wiaty na przystankach nie zawsze są obok słupków, czyli autobus nie zawsze zatrzymuje się obok wiaty, czasem z wiaty trzeba kawałek dojść. Wynika to z faktu, że słupki należą do komunikacji miejskiej, a wiaty do miasta/gminy. Natomiast zawsze przy słupkach zatrzymuje się autobus. Platformy są często bardzo duże i niewidomy stojąc w dowolnym miejscu platformy nie będzie wiedział, gdzie zatrzymuje się tramwaj/autobus - przykład Katowice Rondo.

Last edited by luktar (2020-07-01 11:43:32)

Offline

#37 2020-07-03 15:24:52

maro21
Member
From: Wrocław
Registered: 2018-03-06
Posts: 815

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

masowa modyfikacja przystanków będzie obejmowała dodanie tagu "blind:name"zawierającego nazwę przeznaczoną dla osób niewidomych (nazwa przystanku + identyfikator np. "Katowice Piotra Skargi 1", "Katowice Piotra Skargi 2" itd.)

Jeśli tag "blind:name" ma być konkatenacją name i refu (1,2,...), to lepiej z niego zrezygnować i zrobić raczej tag "blind:ref" lub podobny.
Powielenie nazwy w name i "blind:name" spowoduje, że w przypadku zmiany nazwy przystanku, przeciętny mapujący OSM poprawi nazwę tylko w "name", a w "blind:name" zostanie stara nazwa.
https://wiki.openstreetmap.org/wiki/Nam … amespacing
"over-namespacing leads to inconsistency in the database: if we have projectfoobar:name=xxx and name=xxx, in many cases one will be updated and not the other. The simpler and more generic is the key, the more used it will be, the more curated it will be."

Offline

#38 2020-07-03 21:16:07

Mateusz Konieczny
Member
Registered: 2013-09-22
Posts: 2,257

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

"Refy" nie są honorowane przez wszystkich dostawców aplikacji dla niewidomych. Jedni ich używają (DotWalker) inni nie (Lazarillo, Seeing Assitant Move) i nie zamierzają. Mam to potwierdzone korespondencją.

1) i co to zmienia co do poprawności tagowania?
2) jeśli olewają szeroko stosowany tag to czemu by mieli by stosowac jakiś specjalny?

Choć przyznaje, co do ref mam pewne wątpliwości - co jeśli mamy przystanek o kodzie 4 w ramach danej nazwy a 26726B w ramach pełnej inwentaryzacji obiektów MPK?

Offline

#39 2020-07-03 23:53:18

maraf24
Member
From: Wrocław
Registered: 2015-03-07
Posts: 2,032

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Przykładowe pozycje słupków ZTM dla przystanku Piotra Skargi:

Katowice	Katowice Piotra Skargi	2	50.261809	19.018798
Katowice	Katowice Piotra Skargi	3	50.261939	19.018476
Katowice	Katowice Piotra Skargi	4	50.262097	19.018154

Te 2,3,4 to są local_ref.

Skontaktowałem się również z wiodącymi dystrybutorami nawigacji dla niewidomych i spotkałem się z pozytywnym odzewem jeżeli chodzi o chęć dodania mechanizmu odczytującego dodatkowy tag przeznaczony dla niewidomych.

Podsumowując naszą dyskusję, masowa modyfikacja przystanków będzie obejmowała dodanie tagu "blind:name"zawierającego nazwę przeznaczoną dla osób niewidomych (nazwa przystanku + identyfikator np. "Katowice Piotra Skargi 1", "Katowice Piotra Skargi 2" itd.)

Ten tag jest zbędny, gdyż nie wprowadza żadnej nowej informacji. Skoro są chętni na obsługę nowego tagu, to nie powinni mieć też problemu z łączeniem name z local_ref (lub z innymi tagami).

Offline

#40 2020-07-04 13:29:05

olo81
Member
From: Sosnowiec
Registered: 2012-09-27
Posts: 82
Website

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Tak jak już kiedyś pisałem na innym wątku, jest oprogramowanie do synchronizacji baz danych GTFS z OSM.
https://github.com/CUTR-at-USF/gtfs-osm-sync
Bazy danych z przystankami też są ogólnodostępne https://otwartedane.metropoliagzm.pl/da … format=ZIP

Problem w tym że dane ZTM miejscami są tragicznej jakości. Praktycznie każdy przystanek trzeba przeglądać, są mniejsze lub większe przesunięcia.

Patrząc też na to jak szybko zachodzą zmiany, najciekawszym rozwiązaniem było by przetłumaczenie gtfs-osm-sync, może dostosowanie do polskich realiów i lobbowanie u zarządców za jego używaniem.

Co do nowych tagów to zadał bym pytanie twórcą tych programów dlaczego nie chcą ich obsługiwać . Z wyjaśnieniem że obsługiwanie jakiś nowych wiąże się ze zmianą konwencji tagowania w osm. Jak się okaże że to nieudolność programistów można pomyśleć nad jakąś zbiórką pieniędzy dla programisty który im pomoże big_smile

Last edited by olo81 (2020-07-04 14:14:09)

Offline

#41 2020-07-06 08:40:32

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

maro21 wrote:

Powielenie nazwy w name i "blind:name" spowoduje, że w przypadku zmiany nazwy przystanku, przeciętny mapujący OSM poprawi nazwę tylko w "name", a w "blind:name" zostanie stara nazwa.

Ogólnie planuję, aby tag "blind:name" nie był aktualizowany ręcznie, tylko co jakiś czas automatycznie. Przystanki z systemu ZTM mają unikatowy identyfikator, który również planuję dodać do słupka. Dzięki temu automatyczna aktualizacja stanie się realna. Nie wiem natomiast gdzie mogę umieścić ten identyfikator, skoro ref jest czasem (ale nie zawsze) używany jako numer przystanku. W Łodzi w refie jest pełny identyfikator.

Mateusz Konieczny wrote:

Choć przyznaje, co do ref mam pewne wątpliwości - co jeśli mamy przystanek o kodzie 4 w ramach danej nazwy a 26726B w ramach pełnej inwentaryzacji obiektów MPK?

Tak jak wyżej napisałem faktycznie ZTM ma swój unikatowy identyfikator oraz numer przystanku np. 1, 2, 3, 1t, 2t. Na terenie Śląska w refie jest numer przystanku.
Co powiecie na dodatkowy tag

operator_id=1234567

przeznaczony na identyfikator operatora?

Ps. Na podstawie identyfikatora można również automatycznie zaktualizować pole url.

maraf24 wrote:

Ten tag jest zbędny, gdyż nie wprowadza żadnej nowej informacji. Skoro są chętni na obsługę nowego tagu, to nie powinni mieć też problemu z łączeniem name z local_ref (lub z innymi tagami).

Sugerujesz, żeby zrobić dodatkowy tag "local_ref", który będzie miał tylko numer przystanku i łączyć go z polem name? Dystrybutorzy aplikacji różnie wypowiadają się nt. tagu "ref", natomiast zapewnienie dodatkowego tagu oraz zaprojektowanie sposobu działania mogłoby mieć szansę powodzenia. To rozwiązanie elimnuje duplikację pola "name".

olo81 wrote:

Problem w tym że dane ZTM miejscami są tragicznej jakości. Praktycznie każdy przystanek trzeba przeglądać, są mniejsze lub większe przesunięcia.

To nie dobrze.

Zauważyłem, że ten (https://github.com/CUTR-at-USF/gtfs-osm-sync) program ma możliwość wgrania przystanków do OSM, a później zbierania danych o poprawkach wprowadzonych przez społeczność. Takie dane można by dostarczyć później ZTM usprawniając późniejsze aktualizacje automatyczne.

olo81 wrote:

Patrząc też na to jak szybko zachodzą zmiany, najciekawszym rozwiązaniem było by przetłumaczenie gtfs-osm-sync, może dostosowanie do polskich realiów i lobbowanie u zarządców za jego używaniem.

Niestety to jest Java, my tworzymy program w C#. Możemy się na nim wzorować, ale utworzenie od podstaw programu spełniającego Polskie realia wydaje mi się bardziej prawdopodobne. Ważne, że szlak został już przetarty.

olo81 wrote:

Co do nowych tagów to zadał bym pytanie twórcą tych programów dlaczego nie chcą ich obsługiwać

Jeden z dostawców zapewnia, że jego program jest używany na całym świecie i nie planuje czytania tagu "ref" osobom niewidomym ponieważ w każdym kraju, i jak wychodzi z powyższych zapisów również w każdym mieście, ten tag służy do czegoś innego. Na nowy tag "blind:name" mam wstępną zgodę, pod warunkiem, że będzie ogólnie używany. Nikt nie chce tracić czasu na zmiany w oprogramowaniu z powodu czegoś, co może okazać się niepotrzebne.

Offline

#42 2020-07-07 15:01:10

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Odnośnie bazy pozycji przystanków z ZTM o wątpliwej jakości.

Właśnie dostałem odpowiedź od osoby odpowiedzialnej za tą sprawę, że obecnie trwa inwentaryzacja wszystkich przystanków i proces jest w połowie ukończony. Planowany termin zakończenia inwentaryzacji to koniec sierpnia 2020.
Zakładam, że wtedy baza danych będzie lepszej jakości.

Planujemy zrobić oprogramowanie, które porówna obecne przystanki (miejsce postoju autobusu) z pozycjami słupków (miejsce oczekiwania pasażerów) i jeżeli odległość nie będzie przekraczała kilku metrów to zrobimy update automatyczny, w przeciwnym przypadku będzie wymagana ingerencja człowieka.

Dodatkowo, wg. zaleceń ze strony https://wiki.openstreetmap.org/wiki/Aut … of_conduct zrobimy update przy użyciu małych partii np. po 100 - 200 przystanków.

Z tego względu mam do Was dwa pytania.
Czy macie doświadczenie w weryfikacje tak dużej ilości danych?
Czy istnieje w Polsce społeczność która może nas wesprzeć w weryfikacji zaimportowanych danych?

Offline

#43 2020-08-24 08:30:00

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Właśnie zakończyłem pracę nad planem importu dodatkowych przystanków. Jest on dostępny na tej stronie wiki OSM: https://wiki.openstreetmap.org/wiki/Aut … _the_blind

To jest propozycja i może ulec zmianom, oczywiście na lepsze smile, ale ogólny sens został zachowany.
Wszelkie uwagi są mile widziane.

Największą niewiadomą jest dobór odpowiedniego programowania do zrobienia importu 6500 przystanków. Chodzi o to, aby w przyszłości te przystanki mogły być aktualizowane automatycznie, po wykryciu zmian w strukturze danych dostarczanych przez przedsiębiorstwa komunikacyjne. Będę wdzięczny za podpowiedzi w tym temacie.

Offline

#44 2020-08-27 20:35:55

gscscnd
Member
From: Rybnik
Registered: 2013-08-13
Posts: 174

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Jeżeli stop_id to „the GTFS id from transportaion company for this particular stop”, to dlaczego nie użyć jednego z tagów opisanych na Wiki? Np. gtfs_id albo gtfs:stop_id.

Dlaczego stop_no, a nie local_ref?

Offline

#45 2020-08-29 18:07:53

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

gscscnd wrote:

Jeżeli stop_id to „the GTFS id from transportaion company for this particular stop”, to dlaczego nie użyć jednego z tagów opisanych na Wiki? Np. gtfs_id albo gtfs:stop_id.

Wg. mnie gtfs_id brzmi lepiej niż stop_id, pytanie czy to jest standard?

gscscnd wrote:

Dlaczego stop_no, a nie local_ref?

Rzeczywiście ten tag jest popularny. Dziwne, że analizując klikanaście miast w Polsce się z nim nie spotkałem.

Pytanie do Was - czy użycie pary gtfs_id oraz local_ref jest lepszym pomysłem niż stop_id i stop_no?

Offline

#46 2020-08-31 12:48:36

szydzio
Member
Registered: 2016-07-28
Posts: 644

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:

Największą niewiadomą jest dobór odpowiedniego programowania do zrobienia importu 6500 przystanków. Chodzi o to, aby w przyszłości te przystanki mogły być aktualizowane automatycznie, po wykryciu zmian w strukturze danych dostarczanych przez przedsiębiorstwa komunikacyjne. Będę wdzięczny za podpowiedzi w tym temacie.

Taki import można zrobić nawet samym JOSM z wtyczką Opendata a aktualizować (rozumiem że np. położenie bądź nazwę przy założeniu że stop_id się nie zmienia) w zasadzie nawet tylko w Excelu, bez dodatkowego oprogramowania.

O wiele ważniejsze pytanie jest co chcemy importować.
Na stronie podajesz schemat gdzie zarówno do przystanków autobusowych jak i tramwajowych używasz public_transport=platform.
Problem w tym, że public_transport=platform może być mapowany jako węzeł (najbardziej podstawowa infrastruktura), jako linia (odpowiadający obszarowi peronu) bądź jako obszar (dla najbardziej rozbudowanej infrastruktury). Czyli tam gdzie mamy teraz tylko węzły po imporcie jest OK (scalamy i aktualizujemy położenie), ale tam gdzie mamy public_transport=platform jako linię bądź obszary zasadniczo public_transport=platform występowałby 2 razy, raz jako dotychczasowo zmapowany way lub area i drugi raz jako węzeł.
Dodatkowo widzę problem dla przystanków tramwajowych. Tu planujesz użyć railway=tram_stop. Problem w tym, że w OSM railway=tram_stop używamy jako węzeł na torach, więc z definicji import byłby niepoprawny, bo lokowałby je poza torami.
Zasadniczo z tego co zrozumiałem, zaimportowane miałyby być współrzędne słupków przystankowych? Czyli o ile są one prawidłowo oznakowane w terenie przez zarządcę powinny odpowiadać położeniu znaku drogowego traffic_sign=PL:D-15 / traffic_sign=PL:D-17 (już kiedyś pisałęm o tym w tym wątku).
No i ostatnia kwestia, czyli jakość danych – sprawdziłem sobie kilkanaście przypadkowych danych z importu i niestety wydaje się, że często te współrzędne nie odpowiadają faktycznemu położeniu słupka.

Offline

#47 2020-09-03 18:30:13

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

szydzio wrote:

Taki import można zrobić nawet samym JOSM z wtyczką Opendata a aktualizować (rozumiem że np. położenie bądź nazwę przy założeniu że stop_id się nie zmienia) w zasadzie nawet tylko w Excelu, bez dodatkowego oprogramowania.

Czy ten program (razem z wtyczką) będziemy mogli uruchomić na serwerze, aby robił automatyczne aktualizacje, czy jest raczej przeznaczony dla użytkowników końcowych?

szydzio wrote:

Problem w tym, że public_transport=platform może być mapowany jako węzeł (najbardziej podstawowa infrastruktura), jako linia (odpowiadający obszarowi peronu) bądź jako obszar (dla najbardziej rozbudowanej infrastruktury). Czyli tam gdzie mamy teraz tylko węzły po imporcie jest OK (scalamy i aktualizujemy położenie), ale tam gdzie mamy public_transport=platform jako linię bądź obszary zasadniczo public_transport=platform występowałby 2 razy, raz jako dotychczasowo zmapowany way lub area i drugi raz jako węzeł.

Ciekawa uwaga, natomiast nie rozumiem dlaczego dodatkowy obiekt z tym tagiem mógłby sprawiać problem. Podpatrzyłem to rozwiązanie na przystanku Rybnik Kościuszki, tam właśnie w ten sposób został oznaczony słupek. Czy takie oznaczenie, oprócz nawarstwienia tagów public_transport=platform, coś psuje?

szydzio wrote:

Dodatkowo widzę problem dla przystanków tramwajowych. Tu planujesz użyć railway=tram_stop. Problem w tym, że w OSM railway=tram_stop używamy jako węzeł na torach, więc z definicji import byłby niepoprawny, bo lokowałby je poza torami.

W tym przypadku wzorowałem się na powyższym przykładzie (Rybnik Kościuszki), gdzie słupek autobusowy ma oznaczenie highway=bus_stop.
Jest to zgodne z Wiki:

A bus stop should be defined for each discrete location where a pole or shelter is placed or where a person should wait for a vehicle.

Być może lepiej będzie oznaczyć słupek tramwajowy railway=platform? Źródło.

szydzio wrote:

Czyli o ile są one prawidłowo oznakowane w terenie przez zarządcę powinny odpowiadać położeniu znaku drogowego traffic_sign=PL:D-15 / traffic_sign=PL:D-17 (już kiedyś pisałęm o tym w tym wątku).

Niestety nie do końca rozumiem te oznaczenia.

szydzio wrote:

No i ostatnia kwestia, czyli jakość danych – sprawdziłem sobie kilkanaście przypadkowych danych z importu i niestety wydaje się, że często te współrzędne nie odpowiadają faktycznemu położeniu słupka.

Obecnie trwa inwentaryzacja w ZTM, która się zakończy w połowie września. Tak czy inaczej weryfikacja pozycji słupków jest konieczna i planuję zaangażować w to ZHP. Pytanie, czy można to zrobić przed importem, czy konieczne jest przemieszczanie obiektów już istniejących.

Offline

#48 2020-09-03 19:23:15

gscscnd
Member
From: Rybnik
Registered: 2013-08-13
Posts: 174

Re: Komunikacja miejska dla niewidomych na terenie Śląska

luktar wrote:
szydzio wrote:

Problem w tym, że public_transport=platform może być mapowany jako węzeł […], jako linia […] bądź jako obszar […]. Czyli tam gdzie mamy teraz tylko węzły po imporcie jest OK (scalamy i aktualizujemy położenie), ale tam gdzie mamy public_transport=platform jako linię bądź obszary zasadniczo public_transport=platform występowałby 2 razy, raz jako dotychczasowo zmapowany way lub area i drugi raz jako węzeł.

Ciekawa uwaga, natomiast nie rozumiem dlaczego dodatkowy obiekt z tym tagiem mógłby sprawiać problem. Podpatrzyłem to rozwiązanie na przystanku Rybnik Kościuszki, tam właśnie w ten sposób został oznaczony słupek. Czy takie oznaczenie, oprócz nawarstwienia tagów public_transport=platform, coś psuje?

One feature, one OSM element. Jeżeli na OSM istnieje linia lub obszar public_transport=platform, to jak będzie wyglądać import dla takiego przystanku? Powstanie nowy węzeł highway=bus_stop lub public_transport=platform z tagami gtfs/ref/itp., czy tagi gtfs/ref/itp. zostaną dodane do tego istniejącego obiektu (linii/obszaru)? A jeśli (przed importem) oprócz tej linii/obszaru będzie jeszcze węzeł highway=bus_stop?

(Rybnik Kościuszki jest zmapowany jako węzeł (plus stop_area i stop_postition), więc w obu przypadkach powinien być prawidłowo otagowany po imporcie.)

luktar wrote:

Być może lepiej będzie oznaczyć słupek tramwajowy railway=platform?

Może nie tyle traktować railway=platform jako słupek, co dodać do tych peronów importowane tagi. Jeśli mogą być dodawane do linii i obszarów (ale wtedy nie importujemy współrzędnych), a nie tylko węzłów.

szydzio wrote:

Zasadniczo z tego co zrozumiałem, zaimportowane miałyby być współrzędne słupków przystankowych? Czyli o ile są one prawidłowo oznakowane w terenie przez zarządcę powinny odpowiadać położeniu znaku drogowego traffic_sign=PL:D-15 / traffic_sign=PL:D-17 (już kiedyś pisałęm o tym w tym wątku).

Współrzędne słupków można tak otagować, ale tagi gtfs/ref/itp. raczej należą do highway=bus_stop lub public_transport=*.

Offline

#49 2020-09-03 19:24:18

maraf24
Member
From: Wrocław
Registered: 2015-03-07
Posts: 2,032

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Gdzie można przeczytać licencję dla tych danych? Na https://otwartedane.metropoliagzm.pl/ nie znalazłem jej treści.

Offline

#50 2020-09-24 19:35:37

luktar
Member
Registered: 2019-03-11
Posts: 46

Re: Komunikacja miejska dla niewidomych na terenie Śląska

Wybaczcie opóźnienie w odpowiedzi. Byłem na dość długim urlopie offline.

maraf24 wrote:

Gdzie można przeczytać licencję dla tych danych? Na https://otwartedane.metropoliagzm.pl/ nie znalazłem jej treści.

Zasadniczo nie ma jej na stronie internetowej. Znajdziesz tam tylko odnośnik do Open Definition. Dostałem potwierdzenie, że to jest ODbl po kilkukrotnej wymianie mailowej z przedstawicielami ZTM. Oto cytat:

ztm wrote:

Tak, potwierdzam, że dane były wgrywane na stronę https://otwartedane.metropoliagzm.pl/  na licencji Open Database License (w skrócie Open Data lub ODbl) przy zachowaniu praw autorskich.

Mam nadzieję, że to wystarczy.

gscscnd wrote:

One feature, one OSM element. Jeżeli na OSM istnieje linia lub obszar public_transport=platform, to jak będzie wyglądać import dla takiego przystanku? Powstanie nowy węzeł highway=bus_stop lub public_transport=platform z tagami gtfs/ref/itp., czy tagi gtfs/ref/itp. zostaną dodane do tego istniejącego obiektu (linii/obszaru)? A jeśli (przed importem) oprócz tej linii/obszaru będzie jeszcze węzeł highway=bus_stop?

Planuję zrobić import na dwa sposoby:
1. Jeżeli słupek istnieje to dodam do niego dodatkowe tagi (gtfs_id oraz local_ref)
2. Jeżeli słupek nie istnieje to dodaję nowy + tagi

Słupek planuję wstawić bez względu na to, czy istnieje obszar zaznaczony jako platform (public_transport=platform), czy nie.
Alternatywnym rozwiązaniem jest dodanie tagów do obiektów reprezentujących miejsce zatrzymania się pojazdu (railway=tram_stop lub highway=bus_stop), ale wtedy osoba niewidoma traci rzeczywistą informację o położeniu słupka przystankowego i, co gorsza w przypadku niewyczuwalnych krawężników*, może wyjść przez pomyłkę na ulicę.

* - niskie krawężniki będące ułatwieniem dla osób na wózkach sprawiają kłopot osobom niewidomym, ponieważ nie są oni często w stanie wyczuć białą laską gdzie kończy się krawężnik, a zaczyna ulica. Oczywiście jeżeli zejście z chodnika nie jest oznaczone tzw. ścieżką dotykową (takimi wypustkami)

gscscnd wrote:

(Rybnik Kościuszki jest zmapowany jako węzeł (plus stop_area i stop_postition), więc w obu przypadkach powinien być prawidłowo otagowany po imporcie.)

W tym przypadku planuję wyłącznie dodać do węzła dodatkowe tagi.

gscscnd wrote:

Może nie tyle traktować railway=platform jako słupek, co dodać do tych peronów importowane tagi. Jeśli mogą być dodawane do linii i obszarów (ale wtedy nie importujemy współrzędnych), a nie tylko węzłów.

Czy dobrze rozumiem, że sugerujesz aby dodać tagi do wszystkich obiektów wchodzących w skład przystanku zamiast tworzyć nowe węzły? Wydaje mi się, że to będzie duży problem dla dostawców aplikacji dla niewidomych. W jaki sposób nakierować użytkownika na obiekt, który jest obszarem, nierzadko dość dużym (przykład). Myślę, że już lepszym rozwiązaniem byłoby wstawienie tagów do istniejących węzłów.

Offline

Board footer

Powered by FluxBB