Komunikacja miejska dla niewidomych na terenie Śląska

luktar · 2020-08-24T07:30:00.000Z

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/Automated_edits/luktar/Stop_signs_for_blind#The_opinion_of_companies_producing_navigation_solutions_for_the_blind

To jest propozycja i może ulec zmianom, oczywiście na lepsze :), 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.

gscscnd · 2020-08-27T19:35:55.000Z

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?

luktar · 2020-08-29T17:07:53.000Z

gscscnd:

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:

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?

szydzio · 2020-08-31T11:48:36.000Z

luktar:

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.

luktar · 2020-09-03T17:30:13.000Z

szydzio:

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:

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:

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:

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:

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.

gscscnd · 2020-09-03T18:23:15.000Z

luktar:

szydzio:

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:

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:

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=*.

maraf24 · 2020-09-03T18:24:18.000Z

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

luktar · 2020-09-24T18:35:37.000Z

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

maraf24:

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:

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:

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:

Jeżeli słupek istnieje to dodam do niego dodatkowe tagi (gtfs_id oraz local_ref)
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:

(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:

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.

luktar · 2020-09-30T17:24:36.000Z

maro21 zaproponował w tym wątku, aby unikalny identyfikator przystanku umieścić w tagu ref. Zrobiłem ponowną analizę kilkunastu miast w Polsce i poza nią, i okazuje się, że tag “ref” w każdym innym mieście, oprócz aglomeracji Śląskiej, zawiera właśnie unikalny identyfikator.

Czy nie będziecie mieli nic przeciwko, jak zamienię “ref” na unikalny identyfiaktor na terenie Śląska?

Czy powinienem jeszcze gdzieś zapytać, czy tutaj wystarczy?

maro21 · 2020-09-30T20:31:14.000Z

Ale taki jest standard tagowania przystanków na OSM: tag ref=* to numer przystanku
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
I jest wspierany przez edytory, aplikacje i mapy.

Podobnie z numerem peronu - jest na to tag local_ref. Który też jest obsługiwany przez aplikacje, np: https://www.xn–pnvkarte-m4a.de/#2.5677;48.9452;18

Jeśli chodzi o Katowice, to są tam błędnie wpisane te numery. Mogę ci napisać skrypt poprawiający te numery przystanków.

luktar · 2020-10-01T20:48:31.000Z

Cieszę się, że w końcu trafiliśmy na wspólną płaszczyznę

maro21:

Jeśli chodzi o Katowice, to są tam błędnie wpisane te numery. Mogę ci napisać skrypt poprawiający te numery przystanków.

Byłoby super, natomiast nie wiem na czym miałby polegać taki skrypt.
Może moglibyśmy się jakoś zdzwonić, aby ustalić szczegóły?

luktar · 2020-10-24T21:13:51.000Z

Słuchajcie, wspólnie z kolegą napisaliśmy skrypt, który pobiera wszystkie przystanki z OSM w danym prostokącie i porównuje ich pozycję z przystankami z ZTM. Skrypt wykrywa odległości, różnice w nazwach i inne niespójności.

Najlepiej byłoby jednak porównać obie bazy danych w sposób wizualny, tak aby wyświetlić na jednej mapie przystanki z OSM oraz na dodatkowej warstwie przystanki z ZTM.
Szukałem w internecie narzędzia, które jest w stanie to zrobić i znalazłem stronę http://geojson.io/. Niestety przy 6,5k przystanków strona mówiąc delikatnie się zawiesza i wyświetla niepoprawne dane.
Jeżeli chodzi o JOSM, to pozwala on pobierać podejrzanie małe obszary, które zawierają bardzo dużo danych, ale mogłem nie odkryć jakiejś funkcji. Overpass pozwala filtrować dane na dużych obszarach, ale nie pozwala nałożyć dodatkowej warstwy. Przydałoby się takie połączenie overpass-turbo.eu z geojson.io, które działało by dla dużych datasetów.

Czy znacie i moglibyście polecić takie rozwiązanie?

Przypominam, że po ostatnich ustaleniach planowałem dodać do istniejących przystanków, na terenie śląska, dodatkowe tagi ref (id przystanku) oraz local_ref (nr przystanku). Wychodzi jednak na to, że różnic w przystankach jest o wiele więcej, np. niektórych przystanków z ZTM nie ma w OSM, nie zgadzają się nazwy itd. Pomyślałem, że te rzeczy możemy poprawić przy okazji.

Ps. Baza danych ZTM została odnowiona i przeszła rewitalizację.

PPs. maro21 przykro mi, że zaproponowałeś napisanie skryptu, po czym przestałeś odpowiadać na forum i na maila. Jeżeli coś deklarujesz to przynajmniej miej odwagę odpisać, że deklaracja była nieprzemyślana lub temat Cię przerósł. Osobiście wolę wiedzieć na czym stoję niż pozostać bez odpowiedzi.

rmikke · 2020-10-24T22:05:30.000Z

luktar:

Słuchajcie, wspólnie z kolegą napisaliśmy skrypt, który pobiera wszystkie przystanki z OSM w danym prostokącie i porównuje ich pozycję z przystankami z ZTM. Skrypt wykrywa odległości, różnice w nazwach i inne niespójności.

Najlepiej byłoby jednak porównać obie bazy danych w sposób wizualny, tak aby wyświetlić na jednej mapie przystanki z OSM oraz na dodatkowej warstwie przystanki z ZTM.
Szukałem w internecie narzędzia, które jest w stanie to zrobić i znalazłem stronę http://geojson.io/. Niestety przy 6,5k przystanków strona mówiąc delikatnie się zawiesza i wyświetla niepoprawne dane.
Jeżeli chodzi o JOSM, to pozwala on pobierać podejrzanie małe obszary, które zawierają bardzo dużo danych, ale mogłem nie odkryć jakiejś funkcji. Overpass pozwala filtrować dane na dużych obszarach, ale nie pozwala nałożyć dodatkowej warstwy. Przydałoby się takie połączenie overpass-turbo.eu z geojson.io, które działało by dla dużych datasetów.

Czy znacie i moglibyście polecić takie rozwiązanie?

Przypominam, że po ostatnich ustaleniach planowałem dodać do istniejących przystanków, na terenie śląska, dodatkowe tagi ref (id przystanku) oraz local_ref (nr przystanku). Wychodzi jednak na to, że różnic w przystankach jest o wiele więcej, np. niektórych przystanków z ZTM nie ma w OSM, nie zgadzają się nazwy itd. Pomyślałem, że te rzeczy możemy poprawić przy okazji.

Ps. Baza danych ZTM została odnowiona i przeszła rewitalizację.

PPs. maro21 przykro mi, że zaproponowałeś napisanie skryptu, po czym przestałeś odpowiadać na forum i na maila. Jeżeli coś deklarujesz to przynajmniej miej odwagę odpisać, że deklaracja była nieprzemyślana lub temat Cię przerósł. Osobiście wolę wiedzieć na czym stoję niż pozostać bez odpowiedzi.

Umap pozwala zaciągnąć pliki GPX, GeoJSON do warstw. Do jednej zaciągasz dane z Overpassa, do drugiej co tam dostajesz z ZTM i widzisz.

maro21 · 2020-10-24T22:18:02.000Z

luktar:

PPs. maro21 przykro mi, że zaproponowałeś napisanie skryptu, po czym przestałeś odpowiadać na forum i na maila. Jeżeli coś deklarujesz to przynajmniej miej odwagę odpisać, że deklaracja była nieprzemyślana lub temat Cię przerósł. Osobiście wolę wiedzieć na czym stoję niż pozostać bez odpowiedzi.

Ups. Przepraszam za opóźnienie. Już wysłałem ci w prywatnej wiadomości na OSM.

luktar · 2020-10-25T19:08:29.000Z

rmikke:

Umap pozwala zaciągnąć pliki GPX, GeoJSON do warstw. Do jednej zaciągasz dane z Overpassa, do drugiej co tam dostajesz z ZTM i widzisz.

Potwierdzam, działa całkiem dobrze. Przy 6,5k przystanków się tnie. Będę chyba musiał pomyśleć o mniejszych datasetach.
Czy z tego umapa można wygenerować plik importu lub zapisać dane, w moim przypadku punktów, tak aby można je było zaimportować z powrotem do OSM? Po przeanalizowaniu UI wydaje mi się, że się nie da, ale wolę zapytać.

Taką mapę wygenerowałem: https://umap.openstreetmap.fr/pl/map/ztm_osm_514997#18/50.26254/19.02671

maro21:

Ups. Przepraszam za opóźnienie. Już wysłałem ci w prywatnej wiadomości na OSM.

Dzięki za wiadomość maro21, już odpisałem :).

rmikke · 2020-10-25T22:41:38.000Z

luktar:

Czy z tego umapa można wygenerować plik importu lub zapisać dane, w moim przypadku punktów, tak aby można je było zaimportować z powrotem do OSM? Po przeanalizowaniu UI wydaje mi się, że się nie da, ale wolę zapytać.

Nie bardzo rozumiem pytanie. Przecież to są dokładnie te dane, które do umapa zaimportowałeś, po co chcesz je eksportować?

luktar · 2020-10-26T16:55:07.000Z

rmikke:

Nie bardzo rozumiem pytanie. Przecież to są dokładnie te dane, które do umapa zaimportowałeś, po co chcesz je eksportować?

W tej chwili do UMAP wgrałem dataset z OSM (pozycje przystanków pobrane overpassem jako GeoJSON) i dataset z ZTM (CSV).

Jak wiadomo pozycje przystanków w ZTM i w OSM są różne. ZTM zawiera pozycje słupków przystankowych, a OSM pozycje zatrzymania się autobusu/tramwaju.

Chcę dodać do OSM dane z ZTM, czyli identyfikator przystanku umieścić w pole ref i numer przystanku w pole local_ref, wg. zaleceń maro21.

Nasz algorytm łączy ze sobą większość przystanków ZTM z OSM, ale wiele z nich pozostaje bez pary. Problemy z jakimi się spotkaliśmy to:

zbyt duża odległość miedzy pozycją przystanku ZTM i OSM
niezgodność nazwy
przypisanie dwóch lub więcej przystanków z ZTM do OSM
brak przystanku ZTM na mapie OSM

Aby rozwiązać ten problem potrzebny jest czynnik ludzki, bo żaden algorytm nie jest w stanie połączyć tych przystanków w bezbłędny sposób. Do tego potrzebujemy, albo użyć istniejącego oprogramowania, albo napisać swoje własne (Marcin P. - członek zespołu, będzie jutro prezentował prototyp takiego rozwiązania - jeżeli jesteście zainteresowani to podeślę link do spotkania).

Oprogramowanie powinno działać w następujący sposób:

Wgrywamy dwa datasety na jedną mapę, tak aby się wyświetlały np. przystanki z ZTM na niebiesko, a z OSM na czerwono
Użytkownik sprawdza, czy przystanki zostały połączone w poprawny sposób (np. po identyfikatorze) - ten krok jest niezbędny dla przystanków błędnie zmapowanych przez nasz algorytm
Użytkownik łączy przystanek OSM i ZTM lub, gdy przystanek w OSM nie istnieje, dodaje go na warstwę
Po zakończonej pracy generowany jest plik ze zmianami (np. osmchange - tylko o nim czytałem, nie wiem jeszcze jak działa), który można wgrać do OSM

Umap pozwala wyświetlać dwa datasety (ZTM + OSM), ale nie pozwala wygenerować z warstwy z datasetem OSM pliku importu, który można by wgrać z powrotem do OSM’a.

Na prawdę się staram ten proces opisać w miarę prosto, ale może mi się tylko wydawać, że tak jest. Zachęcam Was do pytań.
Możemy również zrobić spotkanie online - chętnie wyjaśnię cały proces i plan działania.

rmikke · 2020-10-27T13:46:46.000Z

luktar:

Oprogramowanie powinno działać w następujący sposób:

Wgrywamy dwa datasety na jedną mapę, tak aby się wyświetlały np. przystanki z ZTM na niebiesko, a z OSM na czerwono

Użytkownik sprawdza, czy przystanki zostały połączone w poprawny sposób (np. po identyfikatorze) - ten krok jest niezbędny dla przystanków błędnie zmapowanych przez nasz algorytm

Użytkownik łączy przystanek OSM i ZTM lub, gdy przystanek w OSM nie istnieje, dodaje go na warstwę

Po zakończonej pracy generowany jest plik ze zmianami (np. osmchange - tylko o nim czytałem, nie wiem jeszcze jak działa), który można wgrać do OSM

Zasadniczo umap dostarcza tylko wizualizację, ale popatrzyłem, i owszem, da się wyeksportować warstwę z Umap do formatu JSON:
https://www.openstreetmap.org/user/rmikke/diary/394571

luktar · 2020-10-28T21:44:32.000Z

rmikke:

Zasadniczo umap dostarcza tylko wizualizację, ale popatrzyłem, i owszem, da się wyeksportować warstwę z Umap do formatu JSON:
https://www.openstreetmap.org/user/rmikke/diary/394571

Dzięki za instrukcję. Rzeczywiście pobrany plik to GeoJson. Wygląda na to, że można sobie wgrać warstwę, zmienić parametry i pozycję i pobrać plik GeoJson.

Dzisiaj na spotkaniu naszego zespołu doszliśmy do wniosku, że zrobimy osobne narzędzie, które pozwoli nam parować obiekty w graficzny sposób. Będzie to polegało na tym, że wczytamy warstwę punktów z przystankami z OSM i warstwę z przystankami ZTM. Następnie użytkownik będzie mógł kliknąć na obiekt (przytanek) OSM i pasujący do niego obiekt ZTM i pojawi się między nimi linia łącząca. Do połączonych obiektów OSM zostaną dodane dane z ZTM (ref i local_ref). Narzędzie będzie oparte na komponencie JS o nazwie leaflet.

Narzędzie planujemy udostępnić harcerzom i musi być w miarę wygodne. Niestety nie znalazłem (a szukałem w internecie dobrą chwilę) możliwości połączenia obiektów z różnych warstw w UMAPie. To by rozwiązało problem parowania.

olo81 · 2020-11-08T14:51:09.000Z

Ostatnio poprawiałem tagowanie platform przystankowych na Śląsku, kilka osób zmieniało je po swojemu i zainteresowałem się jak to jest z komunikacją w Berlinie i innych miastach Polski. Okazuje że mamy na Śląsku odmienną konwencje od reszty kraju.
Dajemy highway=bus_stop w miejscu zatrzymania a reszta kraju używa tego tagu w miejscu platformy, słupka.

Zmiana tego była by bardzo prosta, wystarczy wykasować z miejsc zatrzymania highway=bus_stop, ale ten tag powoduje że wyświetlają się nazwy na mapie głównej i innych.

I tu jakimś pomysłem po zniknięciu nazw było by zaimportowanie tych słupków z ZTM z tagiem highway=bus_stop. Sprawdziłem teraz świeżą bazę z GTFS i nie są najlepszej jakości niestety. Ale taki zabieg dał by kompleksowe dane. Wystarczyło by tylko przeciągać słupki w miejsce platform, zajęło by to pewnie kilka lat ale nie stracili byśmy żadnych danych, pozyskali dużo nowych.

Takie dane gdyby ozdobić dużą ilością tagów z GTFS można by szybko odnaleźć overpasem, jeśli by się to nie sprawdziło skasować. Jeśli by się sprawdziło łatwo edytować. Można by też ZTM zainteresować.