Nie dostrzegam żadnego wpływu takiej struktury na cokolwiek oprócz właśnie trudności z usuwaniem zlikwidowanych linii.
It’s sorted in (almost) such a way already.
Ja chwilowo nie usuwam disused:route_master=bus z tych relacji.
Myślę że tak łatwiej je przywrócić, gdyby linia powróciła.
Myślę, że obie opcje są sensowne. Powinno być jasne z tagów, że linia aktualnie nie funkcjonuje.
Czy mógłbyś rozwinąć czemu uważasz, że należy je usunąć?
route_master=bus dla jednej linii bywa zdublowana, jedna bardzo stara disused, jako że stara to podpięta pod relację nadrzędną, a druga aktualna nowa może nie być w nadrzędnej. Jeżeli nieprawdopodobne jest by stara trasa została przywrócona (najczęściej takie przypadki są związane z metrem), dla porządku należy usunąć disused i wtedy trzeba usuwanie zacząć od relacji nadrzędnej. Ja tak postąpiłem z linią 109 omijającą kiedyś budowę M2 przez kilka lat. Nowo utworzona linia tramwajowa 78 nie ma relacji nadrzędnych dla route master, a numer wskazuje, że jest tymczasowa, więc jej ten problem nie dotyczy - chodzi o bardzo stare relacje. Nie twierdzę, że wszystkie disused powinny być usunięte.
Yes, I do the same usually. Those routes will then be listed under Więcej relacji
After a while, we usually then delete the relation(s).
Agreed: both Options are valid.
Ok, żle wytłumaczyłem, żle zapamiętałem.
Problem w JOSM. Wezmę przykład.
Tramwaj 29T nieczynny od wielu lat. Na przystankach narastająca ilość disused. Nieprawdopodobne by ten tramwaj wrócił na trasę. W JOSM dla route jest widoczne nadrzędne route master, natomiast w route master nie jest widoczne nadrzędne network i wyskakuje błąd przy próbie usunięcia 2x route oraz route master. Trzeba zacząć od usunięcia tej linii z relacji network Tramwaje Warszawskie. Stąd ten mój listing pokazujący strukturę zależności. Nie wszystkie linie są włączone do relacji network.
Ah, I understand, you’re referring to
I do not actively map such relations as parent relation to route_master. They are considered to be categories or collections and should not be mapped. As you can imagine, those relations are hard to maintain and almost never up-to-date, and this is also my experience. This type of information can be retrieved by Overpass-Api queries as well.
1 Like
Stworzyłem stronę do porównywania danych WTP z OSM: Porównanie danych OSM z WTP
Napisałem o nim artykuł: starsep's Diary | Porównanie danych OSM z Warszawskim Transportem Publicznym | OpenStreetMap
3 Likes
Ważnym do ustalenia w tym wątku jest standard tagowania obiektów z public_transport=platform.
Chwilowo są to węzły, linie lub obszary. Czasami kilka naraz np. zarówno punkt i obszar zmapowany.
Nie widzę powodu tworzenia highway=platform. Sam go nie dodaję, aczkolwiek też nie usuwam.
Tak samo. Co najwyżej deduplikuję.
Ale jak ktoś musi, to w zakresie przystanków trzymałbym się tych propozycji, a więc linia lub obszar.
Te propozycje są spójne z polskimi artykułami na Wiki, jeśli coś w nich jest błędnie/niezrozumiale, to chętnie poprawię.
Po całej dyskusji mam propozycję tagowania:
Droga / Tory
bus=yes / tram=yes
name=*
network=ZTM Warszawa
public_transport=stop_position
ref=*
direction=farward/backward (na drodze dwukierunkowej)
rola w relacji - stop / stop_entry_only / stop_exit_only
Peron - linia / obszar
area=yes / no
bus=yes / tram=yes
highway=platform
bez żadnej relacji
Przystanek - słupek
highway=bus_stop / railway=tram_stop
name=*
network=ZTM Warszawa
network:wikidata=Q8066998
operator=Tramwaje Warszawskie / Miejskie Zakłady Autobusowe / inne
public_transport=platform
ref=*
udogodnienia:
bench=yes
bin=yes
lit=yes
shelter=no
surface=paving_stones
tactile_paving=yes
wheelchair=limited / yes / no
rola w relacji - platform / platform_entry_only / platform_exit_only
Czym różni się ona od propozycji @kubahahaha?
Widzę tyle, że uwzględnia też tramwaje. Problem widzę taki, że railway=tram_stop dotąd zawsze był na torze, a nie w miejscu słupka, bo akurat tutaj wiki dość silnie to precyzuje. Chociaż zgadzam się, że bardziej spójnie byłoby to traktować analogicznie do highway=bus_stop.
Niczym. Chcę tylko uzgodnić i uszczegółowić. Dlatego też:
Analogia jest tak wyraźna, że może warto by było taki system przyjąć.
Właśnie po to stworzono tagi public_transport=stop_position i public_transport=platform, żeby była oddzielna niezależna jednolita klasyfikacja (jeden zawsze na jezdni/torach, drugi w miejscu oczekiwania niezależnie od środka transportu), żeby nie było konieczności przetagowania wszystkiego co już było na mapie 
No i dokładnie tak jest w mojej propozycji.
Do czego służy direction=forward/backward dla public_transport=stop_position?
Na tę chwilę w województwie mazowieckim ma ustawione 108 spośród 11145.
Jak rozumiem oznacza, że dotyczy pojazdów zatrzymujących w danym kierunku względem kierunku linii w OSM.
Mogę zacząć dodawać, nie do końca widzę jak to wykorzystać w praktyce.
Zaktualizuję w takim razie strony na Wiki o public_transport również dla tramwajów.
Mówisz o relacji stop_area czy type=route? Takie wartości będą raczej ważne dla konkretnych linii autobusowych (type=route). Tam też warto wspomnieć o wartości platform_on_demand - też dla linii, a nie dla całego peronu (przystanku).
Odnoszę się tylko do relacji type=route.
Roli platform_on_demand też można użyć w relacji route, ale kiedyś moja próba użycia tej roli napotkała jakiś problem, nie pamiętam na czym polegał.
Użycie direction=forward/backward natrafiłem w czyimś tagowaniu i nie potrafię ocenić jego użyteczności, natomiast wydaje mi się bardzo logiczny, gdy droga jest dwukierunkowa.
W Polsce 25/12 użyć stop_on_demand/platform_on_demand
https://taginfo.geofabrik.de/europe/poland/search?q=on_demand#roles
Na świecie 658/196
https://taginfo.openstreetmap.org/search?q=on_demand#roles
Wygląda raczej na ciekawostkę chwilowo niż na używaną wartość. Nie mogę też znaleźć na wiki.
Obawiam się, że support narzędzi związanych z transportem publicznym będzie słaby.