Gdzieś tu wg https://rj.metropoliaztm.pl/mapa/
https://www.google.pl/maps/@50.1851573,18.8695533,3a,75y,128.13h,66.69t/data=!3m7!1e1!3m5!1s4MQ7COFx4oaaxRyZ6klgqA!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fpanoid%3D4MQ7COFx4oaaxRyZ6klgqA%26cb_client%3Dsearch.revgeo_and_fetch.gps%26w%3D96%26h%3D64%26yaw%3D131.29776%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
Na serwerze już jest wgrana i przetestowana wersja 0.10.0 programu OsmIntegrator.
Film z nowościami w wersji 0.10.0 jest dostępny pod tym linkiem. Dowiecie się w nim o nowo dodanych funkcjach takich jak:
- nowy sposób przypisywania kafelków
- pobieranie danych z OSM
- wysyłanie danych do OSM (import)
- nowe kolory połączeń
- szczegóły kafelka
- przyspieszenie działania połączeń
- nowy sposób wyświetlania nazw przystanków OSM
- usunięcie przypisywania kafelków przez Supervisora
- usunięcie akceptacji połączeń
- dodanie logo ZTM
Instrukcja obsługi jest dostępna dla chętnych pod tym linkiem.
Utworzyłem również dokument z najczęstszymi problemami podczas tworzenia połączeń oraz rozwiązaniami. Można go pobrać pod tym linkiem.
Zachęcam do korzystania z OsmIntegratora i zgłasznia uwag.
Wgraliśmy już kilka mniejszych grup przystanków (do 10 obiektów).
Nasze changesety można wyszukać po tagach #osmintegrator.
Przykładowe numery changesetów: 117638169, 117641639, 117958098.
Teraz planujemy wgrać całe centrum Katowic (ponad 300 przystanków).
Pod tym linkiem udostępniłem changeset oraz plik ze zmianami.
https://drive.google.com/drive/folders/1Aaljzm9M6uPTK5ryhRAnFXIPBpQIBG5a?usp=sharing
Dajcie znać, czy te zmiany są ok?
Natrafiliśmy również na omawianą już wcześniej w tym wątku sytuację z przystankami przypisanymi do więcej niż jednej linii.
Przykładowo przysatnek w Oświęcimiu
https://www.openstreetmap.org/node/2175680126
name = Stacja BP
ref = 1092
W systemie ZTM powinien mieć następujące dane:
name = Oświęcim Stacja BP
ref = 181146
local_ref = 17
Moglibyśmy nadpisać te dane danymi z ZTM, ale nie wydaje mi się to dobrym rozwiazaniem.
Czy macie jakieś pomysły jak rozwiązać ten problem?
Czy mógłbym prosić o ponownie rozważenie wprowadzanych zmian?
Identyfikatory przystanków (znaczniki “ref”) nie pokrywają się z danymi w terenie i na stronie internetowej! Powinny być jednocyfrowe!
Dla działania nawigacji dla niewidomych ich kopia powinna być w “local_ref”, a ukryte wewnętrzne identyfikatory Zarządu Transportu Metropolitalnego powinny mieć własny osobny znacznik. “ref:ztm” jest już zajęty, proponuję użycie “ref:ztmetropolitalnego” lub “ref:ztm-śląsk”.
Twoje zestawy zmian modyfikują tylko punkty zatrzymania (public_transport=stop_position), a nie modyfikują platform przystankowych (public_transport=platform).
W tym wątku ustaliliśmy, że tag ref będzie zawierały 6-ści cyfrowy unikatowy identyfikator z systemu ZTM, a tag local_ref będzie zawierał numer przystanku np. 1, 1t, 2t.
Proponuję zastosować zasadę “ZTM First”, czyli:
Dla wszystkich przystanków ZTM uzupełnimy tag ref unikatowym identyfikatorem ZTM, nawet jeżeli przystanek jest współdzielony z innym dostawcą transportu publicznego.
W następnej wersji OsmIntegratora dodamy możliwość łączenia jednego przystanku z wieloma providerami transportu publicznego i wtedy wprowadzimy podział na ref:nazwa_dostawcy i zaktualizujemy istniejące dane.
Co sądzicie o tym pomyśle?
Zgadza się. Modyfikacja platform nie była przewidziana.
Teoretycznie można to dodać, ale potrzebowałbym chętnego programistę C# i React bo przy takim rozmiarze systemu doba jest za krótka 
Wciąż nie otrzymałem odpowiedzi, dlaczego wprowadzamy nieoficjalne nieistniejące w terenie identyfikatory przystanków. Dlaczego do znacznika „ref” nie wprowadzamy prawdziwych danych z ZTM?
Hej Finvenkulo,
W pole ‘ref’ wprowadzamy najbardziej aktualne i rzeczywiste dane z systemu ZTM. Nie ma bardziej aktualnych danych ponieważ są one wprowadzane przez samych pracowników ZTM z ich wew. bazy danych.
Na początku marca odpowiedziałem na Twój komentarz do changeseta. Komentarz znajduje się pod tym linkiem:
https://www.openstreetmap.org/changeset/117495805#map=16/50.2677/19.0249
Przytoczyłem w nim link do postu z tego wątku, w którym szczegółowo wyjaśniłem dlaczego społeczność OSM umieszcza unikalny identyfikator w tagu ‘ref’, a zrozumiały dla użytkownika numer przystanku w tagu ‘local_ref’.
Link: https://forum.openstreetmap.org/viewtopic.php?pid=834516#p834516
Przykłady:
https://www.openstreetmap.org/node/334559649
https://www.openstreetmap.org/node/369231508
https://www.openstreetmap.org/node/469782076
W mniejszych miastach jak Szczecin, czy Toruń ref oraz local_ref nie są uzupełnione.
Wyjątek zstanowią Poznań i Łódź, w których przystanki nie mają krótkich 1 - 2 znakowych numerów, tylko długie alfanumeryczne identyfikatory.
Temat znacznkówk ref oraz local_ref również opisałem na WIKI pod tym linkiem: https://wiki.openstreetmap.org/wiki/OsmIntegrator#Stops_naming_convention
Mam nadzieję, że powyższe informacje są wystarczające :).
W razie czego możemy się spotkać i pogadać na ten temat.
Ps. Status prac:
- poprawiliśmy już około 3501 przystanków. Pozostało około 3000.
- dane cały czas są aktualizowane w systemie ZTM, w tym pozycje, numery oraz identyfikatory przystanków, co staramy się od razu aktualizować w OSM. ZTM również cały czas dodaje i usuwa przystanki
- każdy przystanek jest starannie sprawdzany przez pracowników ZTM. Poprawiane są również pozycje przystanków na mapie OSM
- efekty prac już są widoczne na openstreetmap.org, w szczególności okolice Tychów, Katowic i Chorzowa
Trafiłeś na tymczasowo nieistniejący przystanek (należy dodać prefiks «disused:»), ale na stronie internetowej sąsiedniego przystanku mamy:
Tutaj rzeczywiście nie znalazłem wartości ze znacznika «ref» na stronie, ale przystanek ten pojawia się po wpisaniu w wyszukiwarce.
Teraz przykład ze Śląska:
https://www.openstreetmap.org/node/2185700388
Znajdź proszę gdzieś na oficjalnej stronie z rozkładami jazdy lub na zdjęciu tabliczki przystankowej numer 159191:
Numer ten pojawia się tylko w adresie (url) strony i w bazie GTFS.
Wprowadzanie tego numeru do znacznika «ref» jest wprowadzaniem użytkowników w błąd, podążając za przykładami Gdańska i Berlina powinno się stworzyć dla nich nowy znacznik, proponuję użyć «ref:ztm_śląsk».
W takim razie to jednoznaczny błąd i nie powinien być do ref pchany.
Finvenkulo bardzo doceniam pracę jaką włożyłeś w zweryfikowanie podanych przeze mnie przykładów.
Z tego co się orientuję nikt w tym wątku nie wspomniał o tym, że zawartość tagu ref powinna przynajmniej znaleźć się na stronie internetowej z rozkładem jazdy. Gdybym to wiedział to inaczej zaprojektowałbym obecne rozwiązanie.
Dostarczone przez Ciebie informacje wprowadziły pewien chaos w obecnym rozwiązaniu. Z tego powodu mam dużo pytań.
Czy dodanie informacji o identyfikatorze do rozkładu jazdy ZTM przyczyni się do rozwiązania problemu?
Co z tagiem local_ref?
Pamiętajmy, że na podstawie naszych ustaleń firmy produkujące aplikacje dla niewidomych dokonały stosownych zmian w algorytmach i ich zmiana będzie bardzo trudna lub wręcz niemożliwa.
Wspomniany wyżej Londyński przystanek “Northumberland Avenue / Trafalgar Square” zaprzecza jednoznaczności.
W czym Gdańsk, czy Berlin są lepsze od Londynu?
Widzę, że mają standard ref:xxx, ale większość miast ma jednak standard z samym ‘ref’.
Nie mówię, że sam ‘ref’ jest lepszy, bo ref z dwukropkiem rozwiązuje problem wielu linii przypisanych do jednego przystanku, ale jednak ten drugi sposób jest stosowany rzadziej.
Czy na stronie Berlińskiego rozkładu jazdy sieci BVG identyfikator przystanku powinien się wyświetlać obok jego nazwy?
https://www.openstreetmap.org/node/3870475228
Niestety tak się nie dzieje: https://qr.bvg.de/h107167
Czy zasada z uzupełnianiem identyfikatora, po dwukropku, w tagu ref została gdzieś opisana?
Jaką mam pewność, że jutro ktoś nie powie, że powinniśmy jednak korzystać z jeszcze innej konwencji nazewniczej lub wrócić do zwykłych refów?
Podsumowując
Obecnie tag ref służy do tego, aby przystanki z OSM były połączone z przystankami GTFS, dzięki czemu możliwa będzie aktualizacja wszystkich przystanków na raz, a tym samym przeniesienie zawartości tagu ref do dowolnego innego tagu (jeśli będzie to konieczne).
Myślę, że naszym wspólnym celem jest sprawienie, aby mapa OSM była bardziej aktualna i zawierała więcej przydatnych dla użytkowników informacji. Żeby to zrobić musi powstać jedna spójna i uniwersalna wersja tego w jaki sposób dodatkowe informacje takie jak numer i identyfikator przystanku powinny zostać dodawane do przystanków.
Dopóki nie mamy wypracowanej wspólnej koncepcji będziemy poprawiać przystanki tak jak to ustaliliśmy we wcześniejszych postach w tym wątku.
Działam troszkę egoistycznie, zdarza mi się korzystać z aplikacji OsmAnd, dlatego też włożyłem trochę pracy w dodawaniu odnośników do rozkładów jazdy:
Przecież mamy ≈1000 przystanków! Chcesz drukować nowe tablice, aby wprowadzać nowe identyfikatory, zamiast zmienić kod Twojej aplikacji?!
Już to pisałem, nic. Może być on kopią znacznika «ref» i wszyscy będą zadowoleni!
Nie ma go na stronie i nie ma go na OSM w znaczniku «ref».
Władze różnych miast stosują różne sposoby oznaczania przystanków.
Na angielskiej wiki: https://wiki.openstreetmap.org/wiki/Key:ref#Key_variations
Polskie apteki mają poprzypisywany znacznik ref:csioz, jakoś autorowi nie przyszło do głowy dodać tego numeru do znacznika ref.
Numery z PRNG: wiki, taginfo.
Chwilowo robisz zamieszanie: na tablicy przystankowej i stronie internetowej mamy jeden numer, do znacznika «ref» miejsca zatrzymania wprowadzasz jakiś inny nieznany numer, a na platformach przystankowych jest znowu poprawny numer.
Przy okazji zauważyłem mój błąd: znacznik «website» służy do wprowadzenia oficjalnej strony obiektu, a «url» do nieoficjalnej, wkrótce to poprawię.
Zaproponowałem dodanie znacznika «ztm_śląsk», tymczasem znacznik ne te 6-cyfrowe identyfikatory przystanków już od dawna istnieje: https://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification i nawet został wprowadzony dla kilku śląsko-dąbrowskich przystanków: https://www.openstreetmap.org/node/3706546042/history
Nie rozwiązuje to problemu kilku przewoźników na jednym przystanku.
Trochę nie rozumiem. Czy mówiąc “odnośniki” masz na myśli tagi ‘url’?
Chodziło mi o rozkład jazdy wyłącznie na stronie internetowej.
Ps. Mamy ponad 6500+ przystanków.
Myślę, że tutaj powinna się wypowiedzieć społeczność. Z tego co mi wiadomo powielanie danych nie jest zbyt dobrą praktyką.
Natomiast w ten sposób można by rozwiązać problem numeracji przystanków w Łodzi i Poznaniu. W tych miastach nie ma rozróżnienia na identyfikator i numer przystanku.
Czy jest gdzieś spisana zasada, że ref musi zawierać identyfikator występujący w terenie oraz ref:xxx może zawierać identyfikator, który nie występuje w terenie? Niestety nie znalazłem tego w podlinkowanych przez Ciebie źródłach.
Nie zgadzam, się z tym, że robię zamieszanie - co najwyżej stan pośredni przed wyniesieniem bazy przystanków OSM na wyższy poziom.
Przeanalizujmy co mamy:
Sytuacja obecna:
a) znacznik ref zawiera identyfikator przystanku
b) znacznik local_ref zawiera numer przystanku
c) o peronach, jak się orientuję, zacząłeś wspominać dopiero Ty
Twoja propozycja :
a) znacznik ref zawiera numer przystanku
b) znacznik ref:metropoliaztm zawiera identyfikator przystanku (zmieniłem ztm_śląsk na metropoliaztm)
c) znacznik local_ref zawiera numer przystanku (kopia ref)
d) perony powinny zawierać taki sam ref oraz local_ref jak przystanki do nich przynależące
Czy dobrze rozumiem?
Wygląda na to, że każdy sobie robi jak chce.
Osobiście już wolę “ref:xxx” od tego “gtfs_id” ze względu na ogarnięcie problemu z kilkoma przewoźnikami.
Przyznam, że śledziłem ten wątek pobieżnie, ale mam wrażenie że 80% dyskusji dotyczy używania tagu ref=*.
Ja używałem tego tagu do oznaczania numerów peronów kolejowych (ref=1, ref=2, itd.) oraz przystanków w rodzaju name=Dworzec Główny 1, ref=1, name=Dworzec Główny 2, ref=2. Jak powinno być?
Tak – i jak już napisałem – dodałem je źle: powinny być w znaczniku «website».
Ref:xxx jest Twoim znacznikiem, Ty ustalasz jego zawartość. Prześledź proszę zastosowanie znacznika «ref» za pomocą overpassa:
-
stacje rowerów miejskich (zdjęcie)
-
paczkomaty: (zdjęcie)
-
stacje transformatorowe: (zdjęcie)
-
bankomaty: w prawym rogu na ekranem
-
drogi: na słupkach
-
miejsca parkingowe: też na słupach
-
maszty telefonii komórkowej: umieszczane na dachach, nie mam do nich wstępu, numery wziąłem z rejestru UKE
-
linie i słupy energetyczne, zwrotnice kolejowe: prawdopodobnie te oznaczenie są gdzieś na nich namalowane
-
kolektury Lotto, kioski Ruch: zazwyczaj na tabliczce z godzinami otwarcia
-
biletomaty: nigdzie?, do usunięcia?
-
przystanki: też nigdzie… a właściwie to są numery na nich tylko inne niż Ty dodajesz
Tak, tylko ja stosuję inne nazewnictwo: identyfikator jest dla mnie tożsamy z numerem (np. „1”), a Twój identyfikator (np. „123456”) jest dla mnie wewnętrznym identyfikatorem ZTM lub numerem w bazie GTFS.
Edytor iD sam proponuje powielanie danych:
-
name=Żabka name:pl=Żabka
-
name=Euronet operator=Euronet brand=Euronet; operator:wikidata=Q5412010 brand:wikidata=Q5412010; brand:wikipedia i operator:wikipedia=coś czego nie powinno być
To co napisał Finvenkulo wygląda logicznie.
Z mojej strony jest możliwe dokonanie zmian wg. schematu:
a) znacznik ref zawiera numer przystanku
b) znacznik ref:metropoliaztm zawiera identyfikator przystanku (zmieniłem ztm_śląsk na metropoliaztm)
c) znacznik local_ref zawiera numer przystanku (kopia ref)
d) perony powinny zawierać taki sam ref oraz local_ref jak przystanki do nich przynależące
Nie chciałbym jednak dokonywać zmian na podstawie opinii jednej osoby.
Co sądzicie o powyższej propozycji?
Ja próbuję się tego dowiedzieć od 2019 roku i czuję, że jestem coraz bliżej ;).
Taginfo wskazuje na to, że ref powinien zawierać unikatowe identyfikatory, a identyfikatory typu 1, 2, A, B powinny znajdować się w local_ref.
Bo iD jest głupi. A ludzie bezmyślnie klikają, bo myślą, że to jakieś błędy.
Nie raz to słyszałem. Pytanie, czy mimo oczywistych problemów z iD rozwiązanie od Finvenkulo jest mimo duplikatów między ref oraz local_ref akceptowalne?
Z perspektywy aplikacji dla osób niewidomych takie rozwiązanie będzie działać nawet jak ‘ref’ będzie puste. Przypominam, że algorytm czytania przystanków działa tak jak na rysunku w tym artykule.
Minęło trochę czasu, a pisałem w tym wątku, a skoro pytasz o zdanie innych, to podrzucę jeszcze swój post na ten temat w którym rozpisałem różne możliwości tagowania i wskazałem potencjalne problemy i powyższa propozycja wpisuje się najbliżej opcji 3 (którą niejasno wskazałem, ale rozpisałem).
Ogólnie z większością tego co pisał użytkownik ☆Finvenkulo się zgadzam, ale po kolei:
a) Z tym się chyba zgadzam i to brzmi super (nie do końca rozumiem, co rozumiesz przez “numer”, bo litery również tam się mogą znaleźć), zgadzam się z poprzednimi wypowiedziami, że “przyjęło się”, że ref powinien być widoczny, bo w terenie może być zupełnie inny, a może być i jego brak, choć również nie wiem, czy gdziekolwiek zostało to opisane, bo do niewidocznych mamy również unsigned_ref, to tak na marginesie, ale może nie mieszajmy, bo transport publiczny, to nieco inny przypadek.
b) Tutaj zgodność, ogólnie unikanie znaków diakrytycznych to dobra praktyka, nie wiem, czy jedynie trochę nie przydługie, bo zwykle te wartości po “:” są skrótowe, ale myślę, że ta nazwa jeszcze jest ok. Tutaj ponownie odwołując się do tego co było pisane wcześniej: również się zgadzam, że “przyjęło się”, że ref:<coś> jako tag referencji z zewnętrznej bazy, który da się w jakiś sposób zweryfikować, ale nie koniecznie musi być np. nadrukowany na przystanku jest ok. Nie mam tutaj potwierdzenia z wiki, ale poprzednie przykłady, takie jak szkoły/apteki, utrzymują mnie w tym przekonaniu.
c) Z local_ref jest kilka problemów, ale wstępnie nie rozumiem trochę tej dyskusji, bo mam wrażenie, że trochę czym innym jest niż tym o czym tutaj dyskutujecie. Local_ref z założenia z wiki jest oznaczeniem na nr peronu/przystanku autobusowego w rozumieniu, że jest to z danej strony ulicy przy założeniu, że mamy np. przystanek w 2+ więcej kierunkach i dla każdego z nich mamy ten inny numer, mimo, że nazwa jest ta sama. Dlatego w danym mieście może być pełno powtarzających się local_ref, a w teorii ref: już się powtarzać na innych przystankach nie powinno (bo to bezsensu).
Ogólnie problem jest taki, że chyba nigdy nie widziałem, żeby to było dobrze używane, ponieważ:
- Jest to mylone z ref, przez co nawet wiki ma już dopisek, że używane jest wymiennie (a szkoda – subiektywna opinia).
- Local_ref jest duplikowany do name – jest to robione prawdopodobnie w większości przypadków tylko i wyłącznie przez kwestie renderu, a raczej jego braku (chyba?), a nr peronu jest raczej dość mocno pożądany w wyświetlaniu, przez co łamana jest zasada tagowania pod render, gdzie tutaj świadomie również ją łamię, ale inna kwestia jest taka, że część operatorów w samych rozkładach dodaje takie cyfry w nazwach, a część nie, stąd może się to również pojawiać na mapie.
Tutaj odnośnie odpowiedzi kubahahaha:
Jak dla mnie jak mamy Dworzec Główny 1, to ref=1 jest ok, jest to duplikat, ale jak mamy więcej takich dworców, to brzmi dla mnie w porządku. Natomiast same perony w obrębie tego dworca już bym oznaczał przez local_ref, ale no tutaj już zgodności nie ma.
- Wracając do mojego posta…kolejnym problemem jest to, że te local_ref mogą się różnić między operatorami (brzmi to tragicznie, ale tak się zdarza), co wtedy? Musimy coś przyjąć/ustalić, to samo się tyczy pozostałych kluczy/wartości, które wymieniłem, bo jak się tego nie ustali, to pewnie będą zmieniane przez mapujących.
d) Przyznaję, że tego nie zrozumiałem, ale może to wynikać z opisanego wyżej punktu c).
Co do powielania danych między kluczami, staramy się ograniczać, ale wydaje mi się, że czasem jest to akceptowalne, choć raczej nie na masową skalę.
Hej, wybaczcie opóźnienie w odpowiedzi. Podczas długiego weekendu nie miałem jak odpisać, ale cały czas o tym myślałem.
Gdy czytałem tego posta, wydawało mi się, że ten problem jest bardzo rzadki. Dzisiaj mogę powiedzieć, że sieć ZTM wchodzi we wszystkie miasta wokół i problem bardzo często występuje.
Jeżeli chodzi o refy, to teraz nie mam już wątpliwości, że tak to trzeba rozwiązać.
Identyfikatory ref:xxx pozwolą na połączenie danych z OSM z danymi z transportu publicznego, a tym samym umożliwią w przyszłości aktualizację wszystkich “połączonych” przystanków na raz.
Natomiast wprowadzanie suffixów dla znaczników local_ref oraz name wydaje mi się trudne do utrzymania.
Dodanie sufixu do name może też kolidować z tłumaczeniem nazw poprzez. Z tego co pamiętam do nazw dodaje się suffix np. name:en=nazwa_angielska lub name:de=nazwa_niemiecka.
https://taginfo.openstreetmap.org/keys/name%3Aen#map
W powyższych przypadkach moglibyśmy zastosować rozwiązanie, które zaproponowałeś dla tagów operator oraz network. Proponuję, żeby name posiadał nazwę przystanku dla głównej linii (na Śląsku ZTM), a tag local_ref zawierał kody przystanków oddzielone średnikiem przy założeniu, że pierwszy kod przystanku dotyczy głównej linii.
Słusznie. Nazwy często zawierają litery np. 1t, 2t. Proponuję zmianę nazewnictwa na kod przystanku, zamiast numer przystanku.
Faktycznie nazwa jest długa. Zastanawiam się co stoi na przeszkodzie stosowaniu nazwy ref:ztm?
W taginfo jest zastosowana tylko 2600+ razy. https://taginfo.openstreetmap.org/keys/ref%3Aztm#overview
W OSM przystanki i perony są w relacji. Przykładowo przystanek “Kościuszki” ma dwa słupki oraz dwa perony po obu stronach ulicy i wszystkie są w jednej relacji. Niestety nie można jednoznacznie zidentyfikować jaki przystanek należy jakiego peronu. Celem dodania ref:xxx do peronu jest jednoznaczne połączenie peronu z przystankiem, tak aby w przyszłości można było automatycznie aktualizować zarówno przystanki oraz perony.
Podsumowując proponuję, żeby oznaczenia wyglądałyby w następujący sposób:
Przystanek autobusowy
name=major_provider_name
ref=local_ref
ref:a=id_a
ref:b=id_b
ref:c=id_c
local_ref=code_a; code_b; code_c
bus=yes
highway=bus_stop
Peron
bus=yes
highway=platform
public_transport=platform
ref=local_ref
ref:a=id_a
ref:b=id_b
ref:c=id_c
Tak teraz myślę, że te refy dla peronu to może być trochę overkill. Może wystarczy pozostawienie samego ref=local_ref, w końcu local_ref powinien być unikatowy w ramach relacji. Można by też zamiast local_ref pozostawić tylko ref:a=id_a, co pozwoliłoby jednoznacznie połączyć przystanek z peronem…