To jest stary sposób oznaczania (ale możliwy i poprawny).
Kiedyś przystanki oznaczało się highway=bus_stop jako węzeł na drodze dla przystanków w obu kierunkach (czasami dwa węzły).
Jest drugi sposób oznaczania, gdzie osobno mapuje się słupek przystankowy, a osobno miejsce zatrzymania.
Hej Olo, właśnie pracujemy nad narzędziem, które w przeglądarce wyświetli na mapie przystanki ZTM oraz przystanki OSM. Przystanki ZTM będą pobrane z najnowszego CSV’a udostępnionego przez ZTM, a OSM będą pobrane Overpassem. Jestem już po wstępnej rozmowie z Komendant Hufca ZHP Katowice. Ideą tego narzędzia będzie będzie możliwość graficznego porównania rozbieżności między przystankami ZHP i OSM oraz połączenia ich ze sobą tak aby jednemu przystankowi OSM odpowiadał tylko jeden z ZTM. W efekcie uzyskamy bazę danych w której będzie zestawiony obiekt OSM ze wszystkimi tagami połączony z odpowiadającym mu obiektem ZTM również ze wszystkimi danymi. Największą zaletą tego rozwiązania jest fakt, że porównania i parowania przystanków dokonają ludzie, a nie automat (który okazał się bezużyteczny).
W pierwotnym planie mamy zamiar zaktualizować przystanki OSM o dodatkowe dwa tagi, o których pisałem już wcześniej i które wg. mnie bardzo słusznie podpowiedział maro21, czyli ref i local_ref.
Mając bazę z połączonymi przystankami będziemy mogli nawet usuwać te tagi po id (OSM) i dodawać słupki wg. wytycznych ZTM (o jakości danych poniżej)
.
Nowa baza ZTM jest pod tym linkiem.
Dostałem informację, że jakość się poprawiła.
W pierwotnym planie nie miałem zamiaru ingerować w pozycję przystanków ZTM, ale być może przy okazji łączenia przystanków ZTM z OSM można by poprawić pozycję słupków ZTM. Na pewno nasze algorytmy wykryły, że w niektórych miejscach nie ma przystanków na mapie OSM, które są w ZTM - te przystanki dodamy.
Mając wsparcie harcerzy ogarniemy przystanki w kilka miesięcy, może nawet w mniej niż kwartał.
Co do edycji mapy przez osoby które nigdy tego nie robiły jestem sceptyczny. Już pierwsza wasza akcja pokazała jakość tych edycji, bubel na bublu. A popsucie relacji jest dosyć proste.
Druga sprawa że jest już jakaś konwencja i stopniowe jej zmienianie spowoduje początkowo konflikty. Jeśli te zmiany nie będą odpowiednio opisane w komentarzach do edycji będzie tak jak ze mną po zobaczeniu tych bubli, będziecie mieć wiele osób nieprzychylnych.
Dobrze się zastanówcie jak to chcecie zrobić, żeby nie skończyło się frustracją.
Myślę, że to kwestia możliwości, jakie się da tym osobom. StreetComplete nie daje dużych możliwości spartolenia. Ma być, jak rozumiem, apka do tego, można ją zrobić tak,eby spartolenie wymagało złej woli.
Maro, a masz może przykłady takich miejsc. Ja znam tylko Rybnik.
Czy to nie koliduje z platformami?
To są stare dane. W ZTM robili ostatnio inwentaryzacje i aktualizowali pozycję wszystkich przystanków. Dane udostępniłem w linku w moim poście. Polecam kontakt z ZTM dla pewności.
Olo konkrety - co się stało, kiedy, kto to zrobił? Bubel na bublu nic mi nie mówi. To było prawie 2 lata temu, a Ty to dalej rozpamiętujesz. Może rzeczywiście coś spartoliliśmy, ale nam tego nie wytłumaczyłeś, tylko warczałeś.
Cofnięcie changeseta nie powinno powodować takiej frustracji. Każdy popełnia błędy, najważniejsze to wyciągać z nich wnioski i iść dalej. Wszędzie znajdziemy ludzi narzekających dla samego narzekania i nic z tego nie wynika. Mam nadzieję, że na dłuższą metę nie należysz do tej grupy osób, bo Twój przedostatni wpis był bardzo ciekawy i konstruktywny. Nawet zapomniałem, że niejako przez Twoje uwagi napisałem na tym forum.
Bez obaw, robimy wszystko zgodnie z Import Guidline i Automated Edits code of conduct co zostało w tym wątku zasugerowane - zresztą słusznie. Wcześniej nawet nie wiedzieliśmy, że coś takiego istnieje.
Dokładnie tak. Tworzymy apkę, która nie da wielu możliwości spartolenia :). Lepiej bym tego nie ujął. Dodatkowo każda zmiana, przez osobę mniej doświadczoną będzie sprawdzana przez dodatkową osobę przed wgraniem do OSM.
Ps. Jeżeli jesteście zainteresowani zaangażowaniem się w tworzenie tego projektu lub wsparcie merytoryczne poza forum to zapraszam do kontaktu osobistego.
Właśnie obserwuję Wrocław i bardzo podoba mi się to rozwiązanie komunikacyjne. Mam jedną wątpliwość odnośnie obszaru pod platformą, tego kawałka chodnika, który ma tagi area:highway=footway.
Podobna sytuacja dla przystanku “Świdnicka” została rozwiązana w taki sposób, że zarówno słupek jak i obszar pod nim ma tag:
To jest dobry przykład, natomiast zauważyłem, że stosowanie słupków nie jest standardem w Warszawie. Są zamiennie stosowane z obszarami, wiatami lub drogami pieszymi.
My możemy wprowadzić do OSM dodatkowe słupki przystankowe ZTM z pozycjami poprawionymi przez ludzi. Słupki mogłyby występować wspólnie z obszarami, wiatami i drogami pieszymi przypisanymi do przystanków, tylko czy to nie zaburzy reguły “one feature one element” opisanej wcześniej przez gscscnd? Czy jest jakiś sposób, żeby umieścić słupki jako obiekty współistniejące?
Ps. Jak mogę wysłać link do obiektu, tak jak to zrobiliście powyżej? W edytorze nie widzę takiej opcji.
highway=bus_stop to jest przystanek autobusowy, zaznaczany w miejscu oczekiwania podróżnych. Być może w tym samym miejscu, co słupek.
public_transport=platform to jest miejsce oczekiwania podróżnych albo peron. Jeżeli przystanek posiada węzeł highway=bus_stop, to ten sam węzeł może otrzymać [pt]=platform. Narysowanie osobno highway=bus_stop i [pt]=platform jest OK, ale narysowanie ich osobno i użycie jednego z tagów na obu obiektach wydaje mi się sprzeczne z one feature one OSM element.
public_transport=stop_position to nie jest słupek.
highway=platform+[pt]=platform mógłby być słupkiem jeżeli nie byłoby obiektu highway=bus_stop.
Wiatę oznaczamy albo jako dodatkowy tag (shelter) do obiektu highway=bus_stop (wtedy wiata może być słupkiem), albo rysujemy jako osobny obiekt.
Był kiedyś tag, który miał oznaczać słupek, ale chyba został zaniechany.
Na openstreetmap.org użyj narzędzia Pobierz i wyświetl obiekty lub Warstwy→Dane mapy, lub wyszukiwarki.
W JOSM zaznacz obiekt i wybierz menu Widok→Szczegóły (strona internetowa) (Ctrl+Shift+I).
W iD (nie używaj iD) zaznacz obiekt i użyj linka Wyświetl na openstreetmap.org znajdującego się w lewym dolnym rogu.
Udostępniając linka pomiń część po znaku # — dzięki temu po jego kliknięciu nie zmienią się wybrane nakładki/warstwy (np. Uwagi).
podział mapy na kafelki zapewni sprawny podział pracy między użytkowników - każdy będzie edytował inny obszar
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:
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?
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?
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.
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.
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.
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.