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?
To pozostałości starego systemu tagowania - kiedyś highway=bus_stop dawało się na węźle drogi (analogicznie do railway=tram_stop na torach), potem doszedł tag public_transport=stop_position. Teraz jest tak jak mówisz.
Pobawiłem się parę chwil i mam uwagi:
Według wiki jak coś tam porobię, to mam guzik ładowania do OSM. W rzeczywistości mam guzik przesyłania kafelka do weryfikacji, który krzyczy na mnie, że dalsze zmiany nie będą możliwe. I nie wiem - klikać? Nie klikać? Jak kliknę to już przerąbane, czy po prostu załaduje dane do OSM? Z drugiej strony, jak nie kliknę, to stracę efekty pracy, czy gdzieś to się zapisuje?
Gdzieś powinno być napisane, co robić w poszczególnych sytuacjach. Jest jeden przystanek w OSM, dwa z GTFS, co robić? Jest przystanek w OSM i nic z GTFS, co robić?
Dużo szybciej by się pracowało, gdyby w trybie łączenia było widać ref przy przystankach z OSM
Jeśli była ta zmiana co do highway=bus_stop to dużo wcześniej niż public_transport=stop_position się pojawił - albo wymieszane też było
Wersja MVP oprogramowania pokrywa tylko obszar jednej sieci, czyli ZTM. Wiemy, że problem ze współdzieleniem przystanków występuje, ale jeszcze się za niego nie zabraliśmy.
Z moich obserwacji wnioskuję, że utrzymanie tak wielu dodatkowych tagów może nastręczać trudności, aby nie popełnić w nich błędu i o wszystkich pamiętać.
Gdyby założyć, że przystanki są łączone w osmintegrator.eu, to wszystkie tagi można by dodać na raz w jakikolwiek sposób.
Patrząc z perspektywy producentów aplikacji dla niewidomych to tag ref, name i local_ref powinny pozostać bez żadnych dodatkowych nazw.
Super, że potestowałeś 
Wstępny zamysł aplikacji (to co jest na produkcji) był nieco inny niż to co napisałem na Wiki.
W wersji nad którą pracujemy zmiany będzie można wgrywać bezpośrednio do OSM z poziomu aplikacji wg. schematu pod tym linkiem.
Dobry pomysł. Zrobiłem już analizę kilku obszarów i to są jedne z najczęściej występujących błędów. Wraz z wersją 0.10.0 powstanie taki dokument.
Premiera nowej wersji będzie pod koniec stycznia lub na początku lutego.
Gdzie dokładnie miałby się wyświetlać? W jakim celu wykorzystałbyś tą informację?
Na śląsku ref w większości jest pusty lub zawiera numer przystanku (1 - 2 znaków).
I w przypadkach, gdy nie jest pusty, zwykle odpowiada numerowi przystanku z GTFS, więc można je połączyć bez skakania między trybem podglądu danych, a trybem łączenia i upewniania się trzy razy, że łączę właściwe przystanki. Umieścić można choćby tu:
Ale myślę, że można to zrobić jeszcze lepiej, przy okazji opędzając problem najczęstszych błędów. Można dla przystanków z OSM, w trybie podglądu danych, dodać przycisk “Połącz”, po czym wybiera się przystanek z GTFS. Ref z OSM widać, bo jesteś w trybie podglądu danych, numer z GTFS widać w nazwie. Podobnie można obok dodać guziki “Ten przystanek odpowiada dwóm lub więcej przystankom z GTFS” i “Ten przystanek nie ma odpowiednika z GTFS”.
A dałbyś radę przydzielić mi jeszcze raz ten kafelek, na którym testowałem, zrobiłem kilka przystanków i posłałem do weryfikacji? Na południe od kafelka, który nadal mam przydzielony.
A ja jeszcze zapytam jakie tagowanie jest poprawne na OSM:
Sytuacja którą rozumiem i znam:
Sytuacja na Śląsku:
wtedy wchodzę ja i edytuję to na:
I teraz pytanie - info o udogodnieniach gdzie dodawać? Na pewno nie 1, nie 2 (różne kierunki mogą mieć różne), 3 czy 4?
3 wchodzi w skłąd relacji transportu publicznego, a 4. np. w tym projekcie. Te tagi (shelter, lit, bin) tagi powinny być i tu i tu, czy gdzie?
Sprawa ma się tak.
Kiedy mapowane były pierwsze przystanki na Śląsku, to obecny schemat tagowania jeszcze nawet nie istniał. Co do tego czy highway=bus_stop tagować na drodze czy obok toczyły się dyskusje. Żeby każdy był zadowolony, zaproponowano tag public_transport, gdzie stop_position będzie zawsze dla węzła na drodze, a platform obok drogi, niezależnie od tego gdzie jest highway=bus_stop. Dopiero później wykrystalizował się podejście, że highway=bus_stop powinie być raczej zawsze obok drogi. Wtedy niektórzy stwierdzili nawet że highway=bus_stop ≡ public_transport=platform i zaczęli robić dziwne masowe edycje bez sprawdzania konkretnego przypadku. Co jest bez sensu, bo gdyby nowe tagi byłyby znaczeniowo 1:1 to nikt nie wymyślałby nowego tagowania. Z grubsza było tak jak @maro21 pisał.
Także po kolei.
Jeśli ten węzeł leży obok drogi, to public_transport=stop_position jest błędem i powinno być public_transport=platform. Jeśli jest na drodze, to lepiej usunąć tag highway=bus_stop z węzła na drodze i dodać go na osobnym węźle obok drogi.
Jeśli zastanawia Cię czemu dalej występuje pomieszane tagowanie, to spróbuj poprawić wszystkie kilka tysięcy przystanków i pogadamy jak się bawiłeś 
Jak dla mnie raczej węzeł highway=bus_stop, który jest w końcu „głównym” obiektem oznaczającym przystanek, a w modelowym przypadku powinien być też otagowany public_transport=platform który już wchodzi w skład relacji linii autobusowej. Oznaczanie platform jako obszary powoduje problemy wynikające z tego, że niektórzy przyjęli za założenie że highway=bus_stop ≡ public_transport=platform… Doszedłem do wniosku, że można z tego wybrnąć i sprostać założeniom różnych stron, tagując węzeł jako highway=bus_stop+public_transport=platform a linię/obszar jako highway=platform, ale chyba trochę to mało eleganckie… Mimo to lepszej opcji nie widzę.
1-2 znakowy kod przystanku powinien być w local_ref, to już chyba było nawet w tym wątku kilka razy poruszane?
A co powiesz, żeby się wyświetlił tutaj?
https://drive.google.com/file/d/1oazvhKLQYVazFRUbrxuvS97uCxDO6xke/view?usp=sharing
Zgadzam się, ale obecnie w ref jest to co powinno być w local_ref. Zastanawiałem się po co rmikke potrzebował refa, ale teraz już wiem
Mam też dobrą wiadomość, ponieważ ZTM zgodził się nas wesprzeć trzema pracownikami z dostępem do najbardziej aktualnych baz przystanków. Dzięki temu możemy zaktualizować OSM najbardziej rzetelnymi danymi, a tym samym z tych danych skorzystają niewidomi.
Mam pewien pomysł.
W osmintegrator.eu wyświetlają się przystanki OSM (pozycja zatrzymania autobusu) i ZTM (pozycja słupka lub wiaty). Te drugie są pobrane z bazy danych ZTM i mają słabej jakości pozycję GPS.
Gdyby dodać do aplikacji możliwość poprawienia pozycji przystanków ZTM to czy nie warto byłoby je wgrać do OSM?
Ależ jak najbardziej, o ile nie jest to znacznie trudniejsze.
Tylko im dłużej o tym myślę, tym sensowniejsze wydaje mi się drugie rozwiązanie (łączenie z trybu podglądu).
Ok doałem ten ref do tooltipa. Przy okazji wyświetla się też local_ref zaraz po nazwie (jeżeli istnieje).
https://drive.google.com/file/d/17r3RK-J0Po_pd_EnbOVgRyNH2iGJHeQL/view?usp=sharing
Zmiana będzie dostępna wraz z wersją 0.10.0 pod koniec stycznia lub na początku lutego.
Nawet nie wiem czy licencja tego nie wymaga (a przynajmniej udostępnienia tych danych) 
@dzamper dzięki, właśnie próbowałem to poprawiać i też wydaje mi się że to najlepsza opcja.
No i zastanawiam się czy jak ktoś poprawi te przystanki u nas (przeniesie highway=bus_stop) na węzeł nie na jezdni, to nie zepsuje waszej aplikacji.
https://www.openstreetmap.org/user/kubahahaha/diary/398500 - napisałem w jaki sposób ja poprawiam te przystanki, może komuś się przyda.
W przypadku, gdy jest tylko jeden słupek na dwa stanowiska, a po drugiej stronie nie ma jakiejkolwiek infrastruktury, mapujemy jeden czy dwa punkty? xD
W sensie po drugiej stronie drogi?
A gdzie stają autobusy?
Gdzie ludzie czekają?
