Bus ZTM Warszawa

Ostatnio poprawiam przystanki autobusowe transportu miejskiego w Warszawie. Używam schematu, który wydaje mi się optymalny:

  1. Na drodze(węzeł) miejsce zatrzymania z rolą w relacji - stop, stop_entry_only, stop_exit_only:
    bus=yes
    name=*
    network=ZTM Warszawa
    public_transport=stop_position
    ref=*
  2. Przystanek (węzeł) - miejsce oczekiwania z rolą w relacji - platform, platform_entry_only, platform_exit_only:
    highway=bus-stop
    name=*
    network=ZTM Warszawa
    public_transport=platform
    ref=*
  • wszystkie udogodnienia
  1. Peron (linia) krawędź, przy której zatrzymuje się bus, bez żadnej relacji:
    highway=platform
    public_transport=platform
    tactile_paving=yes/no
    Ten element traktuję jako infrastrukturę drogową mogącą istnieć nawet gdy żadna linia go nie obsługuje i może oznaczać, że jest tam fragment jezdni pomalowany zygzakiem, krawędź chodnika z tactile_paving lub zakaz zatrzymywania (bodajże 15 metrów) związany ze znakiem “przystanek autobusowy”. Łączę go na końcach z przebiegającą obok ścieżką pieszą za pomocą highway=footway, fooway=access_aisle.
    Jakie są wasze opinie w tym temacie? Ten schemat zastosowałem np. na ulicy Grzybowskiej w Warszawie.

po co są dwa osobne public_transport=platform?

Jeśli już mapować public_transport=platform to mapowałbym to jako obszar i dałbym tam też highway=bus_stop

public_transport=platform - wymagają walidatory.
highway=bus_stop - jest na węźle przystanku i tylko tam powinien być wg wiki.
area=yes unikam bo nawigacja lata po obrzeżach, jeszcze nie wiem jak będzie z przystankami tramwajowymi.

można je olać, nie ma potrzeby podążać za nimi na ślepo

a jak jakiś walidator namawia cię do duplikacji public_transport=platform to na pewno jest on do olania

1 Like

Zgadzam się public_transport=platform na highway=platform może być zbędny. Prawdopodobnie jest tylko wygodny do pracy z JOSM bo wyraźnie renderuje go w widoczny sposób.

Dlaczego public_transport=stop_position tylko rola stop? Jest też stop_entry_only, stop_exit_only

Możemy rozważyć dodanie do NSI (Name Suggestion Index) jeżeli jakieś tagi będą wspólne wszędzie. Chwilowo tagowanie przystanku: Name Suggestion Index

Zgadzam się, że warto ustalić wspólny, prosty schemat tagowania.
Należałoby przetagować całe miasto (dużo pracy oczywiście) oraz pilnować zmian. Część błędów wykrywa PTNA - PL-14-ZTM-Warszawa

Niedopatrzenie, poprawiłem role stop.
Z PTNA korzystam, jest bardzo pomocne.

Popieram wątpliwość. Sam mnie bodaj (Tetryk) odsyłałeś do tego opisu schematu tagowania, gdzie podwójnego użycia public_transport=platform nie ma.

Oczywiście routery działają różnie, ale dla mnie nie powinny w ogóle prowadzić po highway=platform, tak jak nie prowadzą po linii np. highway=rest_area, a co za tym idzie nie ma potrzeby łączenia highway=platform z drogami pieszymi.

Ok, zgoda. Niepotrzebne na highway=platform jeśli jest na węźle highway=bus_stop. Jak już wspomniałem pracuję w JOSM i tam ten tag wyraźniej renderował linię highway=platform, zdawało mi się, że nie przeszkadza. Skoryguję swoją propozycję.
Jeszcze przedstawię swój punkt widzenia na linię platform. Często w obszarze chodnika ciężko jest określić obszar przystanku, a linia w moim zamyśle wyznacza krawędź tego chodnika do wsiadania i miewa swoje oznaczenia - zygzak na jezdni, zasięg zatoczki, tactile_paving itp.
Jeśli chodzi o area dla platform to oczywiście są przystanki, których inaczej określić się nie da, ale czy powinny one zawierać w sobie węzeł highway=bus-stop i być wyłączone z relacji, wtedy zmapowane byłyby niezależnie od tego czy obsługują jakąś linię, czy też bez węzła zawierałyby wszystkie tagi przystankowe. Jaka jest wasza opinia?

Z łączników access_aisle się wycofuję. To była próba by OSM Inspektor nie wyświetlał w Routingu platform jako niedostępnej wyspy.

Jednak pierwszego wpisu nie mogę już edytować do poprawek (albo nie potrafię).

Widzę, że dyskusja utknęła. Chęć ulepszenia mapy, zwłaszcza bez znajomości angielskiego (i programowania), jest bardzo trudna.
Po zastanowieniu mam jeszcze kilka uwag.

highway=bus_stop jest tagiem dla węzła (wg wiki) i na węźle w mojej propozycji jest.

Pytanie zasugerowało mi, że jest to błąd. A właściwie dlaczego? Ten sam tag nie może znajdować się na dwóch obiektach przystankowych? Przecież na węźle highway=bus_stop dodajemy informacje np. o udogodnieniu przystankowym tactile_paving i jednocześnie możemy je umiejscowić w highway = platform.

bo w rzeczywistości jest jeden obiekt

One feature, one OSM element - OpenStreetMap Wiki ( Pl:Jeden obiekt, jeden element OSM - OpenStreetMap Wiki )

dodatkowo, mapowanie różnych informacji typu shelter=yes trzeba by robić wielokrotnie

1 Like

Moim zdaniem jest to tylko spór semantyczny. W rzeczywistości obiekt “przystanek” jest jeden, pełna zgoda. Natomiast określa go kilka obiektów (według mojego rozumienia) na mapie. Jedne mogą występować tylko jako węzeł, inne tylko jako linia lub obszar. Podobnie jak w zalinkowanym przykładzie budynku, gdzie w rzeczywistości pomieszczenie sklepu nie może być odrębnym obiektem, a ten sam sklep oznaczamy osobnym mapowym obiektem “sklep” i chyba tagi adresowe można powtórzyć.
Na przystanku oczywiście mapujemy tagi wielokrotnie: name, network, ref.

Poruszyłem ten temat na starym forum i potem po dyskusji wyedytowałem powiązane strony na Wiki.

Tak jak inni mówią - zawsze daję public_transport=platform tylko na węźle highway=bus_stop - żeby dla jednego przystanku był jeden. Sam peron tylko jako highway=platform, ale prawdę mówiąc często można go w ogóle pominąć.

Zrobiłem kiedyś całą komunikację miejską w Chełmie, a ostatnio Grodziskie Przewozy Autobusowe - możesz zobaczyć jak to tam robiłem (chociaż wcześniej chyba prawie nie było highway=platform, a sam ich raczej nie dodaję.

Informacje takie jak shelter, lit, bench, bin itp. dodaję zawsze do węzła z highway=bus_stop, dużym problemem jest to że często jest on oznaczony na drodze, kiedyś takiego Overpassa używałem do szukania takich błędów.

Do JOSM jest fajna wtyczka - CustomizePublicTransportStop - stawiasz węzeł w miejscu oczekiwania i po naciśnięciu “U” dodaje ci relację i punkt w miejscu zatrzymania (tylko trzeba uważać jeśli do relacji dodajesz kilka przystanków z różnymi nazwami (Główna 01, Główna 02 itp.).

Mógłbyś napisać co warto poprawić w artykułach na Wiki? Ja je po tej dyskusji na starym forum napisałem je prawie od zera, bo wcześniej to kompletnie nie dało się zrozumieć o co chodzi.

@starsep: role stop_entry_only, stop_exit_only, stop_on_request dotyczą relacji linii autobusowej, a nie przystanku (stop_area).

1 Like

Myślę, że w dyskusji zawsze można dojść do wspólnych wniosków, tylko trzeba uzgodnić początkowe pojęcia, którymi będziemy się posługiwać w argumentach dla konkretnej kwestii (np. powiedzenie “w sieci” ma różne znaczenia, zależnie od tego w jakiej dziedzinie toczy się dyskusję). Niestety umiem tylko “tetryczyć”, nie umiem swobodnie poruszać się w sieciach społecznościowych i nie bardzo mam parcie by się tego uczyć.
W OSM elementy (“obiekty”) przystanku uważam za spójne, ale wymagające choćby lokalnego usystematyzowania ich szczegółów.

Zacznijmy od highway=platform, czyli pkt 3 mojego otwierającego wpisu.

Oczywiście jako obszar gdy jest wyraźną wyspą, a linią gdy jest krawędzią chodnika. Oznaczałbym public_transport=platform bo należy do transportu publicznego. W rzeczywistości istnieją bowiem przystanki prywatne (również w formie wyspy peronowej) np. obsługujące centra handlowe lub lotniska, które możemy oznaczyć tylko highway=platform. Nie widzę problemu, że tagi się powtarzają w “obiektach” przystankowych, jeżeli przyjmiemy, że do relacji linii w roli platform włączamy highway=bus_stop i nie jest on na drodze. Ponadto umieszczałbym węzeł highway=bus_stop, gdy platform jest obszarem wewnątrz tego obszaru. Wtedy PTNA oznacza punkt przystanku a nie obwiednię platform i wygląda przejrzyściej.
kubahahaha widziałem, że oznaczałeś krańce linii highway=platform jako ślepej drogi, ja próbowałem zastosować na takich krańcach łączniki z chodnikiem, ale w sumie okazało się to zbędne.

Jak powinny być tagowane linki do rozkładów dla relacji type=route oraz type=route_master?
  • url
  • website

0 voters

Przykładowy link Rozkłady jazdy – Warszawski Transport Publiczny

Proponuję w tagach relacji dodać wersję trasy uwzględnioną w rozkładzie jazdy WTP w postaci zakładek A, B itd. Moim zdaniem najlepiej w name, np. name=Bus 112A: CH Marki => Karolin.

Sam tak zrobiłem dla autobusów w Tczewie np. Relation: ‪Bus 3‬ (‪12657154‬) | OpenStreetMap
Jednak jest to inny przypadek, bo ludzie używają tego w rozmowach, litery wariantów są wyraźnie zaznaczone w rozkładach i nr linii + litera wariantu jest wyświetlana na autobusach.

W przypadku Warszawy mam wątpliwości, bo chyba nikt realnie tego nie nazywa jako pasażer. Z drugiej strony name dla route=bus jest głównie używane przez mapperów. Nie kojarzę aplikacji korzystającej z tej nazwy

Oczywiście chodzi mi o maperów. Z punktu widzenia pasażera wersje tras są jedną wielką tragedią. W czasach map papierowych nawet trasy pokrywające się w 90% miały różne numery i na pytanie czym dojechać tu i tu dostawało się konkretną odpowiedź. Teraz często nawet obyty (korzystający często ze zbiorkomu) warszawiak jest zaskoczony, że nie może dojechać tam gdzie zamierzał bo się okazuje, że dla własnej wygody urzędnik skrócił trasę do wersji B i wyrzucają go (pasażera) w połowie drogi. A od mnogości kartek z godzinami odjazdów jednej linii na przystanku można dostać oczopląsu, bo w tytule jedna od drugiej się nie różni.

Transport publiczny w Warszawie ma nadrzędne relacje:
3652280 name=Transport Publiczny Warszawa
grupuje:
3651336 name=Zarząd Transportu Miejskiego

  • 3651335 name=Linie Autobusowe
  1. 3651331 name=Linie zwykłe (100-299)

  2. 3651332 name=Linie zwykłe okresowe (300-399)

  3. 3651328 name=Linie przyspieszone okresowe (400-499)

  4. 3651327 name=Linie przyspieszone i ekspresowe (500-599, E)

  5. 3651329 name=Linie strefowe (700-899)

  6. 3651326 name=Linie nocne (N)

  7. 4656333 name=Linie strefowe uzupełniające (L)

  8. 9058390 name=Inne linie

  • 3651333 name=Tramwaje Warszawskie

3652267 name=Kolej Miejska Warszawa
3652266 name=Warszawski Rower Publiczny

Przy usuwaniu niektórych nieczynnych linii (bardzo stare disused) trzeba je usunąć również z tych relacji.

Does it make sense to sort/structure the CSV list for PTNA in a similar way?