Jakie jest źródło tego adresu? E-mapa pokazuje 55.

> więc ze względu na dodatkową informację w postaci numeru peronu, musimy nagle wymyślać nowy tag, zamiast wykorzystać istniejące?

Nie musimy wymyślać nowego. Można wykorzystać istniejące.

> railway=platform_edge

To jest coś kompletnie innego i tam nie widzę żadnego problemu, żeby używać ref od danego toru. To już jest "czysto kolejowy" obiekt, nie ma bezpośredniego związku z "publicznym transportem" w znaczeniu "systemu".

> Inna strona, która również odwołuje się do railway=platform jednak powiela tagowanie ref=*

To dość naturalne, że kolejowe trzymają się "swojego" na pochodnych stronach.

> Nie zliczę, ile razy w Polsce widziałem niespójne i niepoprawne tagowanie z wartościami name=* i ref=* zamiast railway:track_ref=*, service=* i usage=*, co wiele stron na wiki rozróżnia.

Nie rozumiem w sumie co to wnosi do tematu.

> A to, że większość osób "uzna to za błędne", bo 1) mało kto czyta wiki 2) tłumaczenie na iD niektórych znaczników odbiega od "znaczeń" tych na wiki (typu frequency=*)

Zaczynając od drugiego – nie korzystam z iD od dłuższego czasu. Fakt może być problemem niestety nie tylko w tłumaczeniach, ale i forsowaniu dziwnego tagowania,, z czym się już zetknąłeś na pewno :)
Większość osób, co klika w kolej, czy transport publiczny chyba raczej też nie?
Co do 1, tak pewnie jest, ale ponownie, wysłałem wyżej przykład, dla którego nie ma to znaczenia – ponieważ mamy sprzeczność między koleją, a transportem publicznym gdzie oba tagi się spotykają.
Skąd ktoś ma wiedzieć, którego powinien użyć?

> Strona o tagowaniu kolei stanęła na dwa lata, więc uznałem, że ją rozwinę w oparciu o analizę danych z mapy i źródła

I fajnie, szczerze szanuję i doceniam za poświęcony czas i wkład.
Nie odbieraj moich komentarzy jako atak (jeśli tak zabrzmiały).

> W związku z czym nie można uznać, że sobie "ustanowiłem', że tak ma być, bo miałem widzimisię xDD

Dla mnie nadal tak może być, spójrz na to z innej perspektywy – nie było w języku PL i "nagle jest" użyte jako argument – to zawsze budzi kontrowersje niezależnie od poprawności.

---

Tak długo jak wiki będzie twierdziło w publicznym transportcie, że ref to nr peronu, a kolej, że to nr toru, to będzie sprzeczność i będzie to mieszane i zmieniane. Jedyne co można z tym zrobić to: lokalnie ustalić własne zasady w Polsce (wątek na forum zalecany i pewnie można to ogarnąć w kilka dni jak nie będzie sprzeciwu i wtedy po problemie), lub/i spróbować zmianę globalnie (to już potrwa, o ile w ogóle przejdzie) – te przykłady co podsyłasz oczywiście się mogą przydać.

Ja się nie upieram przy ani jednym, ani drugim rozwiązaniu, po prostu nie podoba mi się aktualny stan, bo jest to sprzeczne tagowanie i może mylić przez brak spójności w szczególności w odniesieniu do rzeczywistości oraz sposobu refowania reszty systemu publicznego transportu. Co do `local_ref` to może być i niezły pomysł, żeby tym numerować perony, bo co do samego zawierania się w nazwie, to z tym różnie bywa, niektórzy mogą nie być przekonani do powielania "Peron" z tagiem na peron, ale to już niekończąca się dyskusja o nazwach w OSM.

> Tag ref=* na peronie określa numer toru, przy którym znajduje się dany peron.

To nie jest do końca prawda.

Sam to dodałeś do wiki, to nie wygląda dobrze, bo sam sobie to ustanowiłeś. Domyślam się, że jednak tylko tłumaczyłeś, ale może zbyt szybko...

> Proszę sobie zobaczyć, jak są otagowane perony na stacji Berlin Hbf

To akurat nie jest dla mnie argument jak jest w innym kraju i w szczególności dla kolejowych rzeczy dobrze wiesz, że tagowanie znacząco się różni per kraj.

Niestety wiki kolejowe tworzy pewnego rodzaju bańkę, czasem przepychając konfliktowe/nieprawidłowe tagowanie (patrz np. na lifeprefix construction/proposed).

W tym przypadku jak spojrzysz na wiki, do którego nawet to co podesłałeś odsyła, to jasno wskazuje że ref razem z `railway=platform` to nr referencyjny peronu, nie torów.

railway=platform

W dodatku jeśli na peronie będzie `public_transport=platform`, to również to się `ref` będzie zawsze odnosił do "przystanku", a nie torów. Tak też będą przetwarzać konsumenci (nie stricte kolejowi).

public_transport=platform

---
Nie chcę wywoływać wojny edycyjnej w tym momencie, ale proponuję zmiany tagu na inny, bo przypuszczam, ze zdecydowana większość w ten sposób właśnie potraktuje ten tag i część może go po prostu usuwać. Jest to nielogiczne jeśli masz np peron2, a dostanie ref 1, albo idąc w skrajniejszy przypadek, masz 8 torów i dasz ref 6 do peronu nr 2.

Zachęcam do poruszenia tego problemu na forum (najlepiej w języku ang), bo warto to przedyskutować pewnie globalnie skoro twierdzisz, że dworzec w Berlinie jest tak otagowany. Choć lokalnie też warto skoro tak bardzo się to różni międzynarodowo.
Może być tak, że inne kraje nie mają z tym problemów przez to, że u nich jest to spójne, a u nas jest jak jest.

Do not change boundaries if you don't know what are you doing. It's not an error. It doesn't have to be a straight line.
Reverted (141794232)

Dzięki!

To nie wygląda na poprawną zmianę.
Jest to kontrowersyjne, ale takie przejścia nie bez powodu mają odpowiednie tagowany access, zapobiega to własnie błędnemu nawigowaniu jeśli ktoś doda w nieprawidłowy sposób.

Tak długo jak da się przejść i nie ma żadnej fizycznej bariery (np. płot, czy wysokie ekrany akustyczne) nie powinno to być usuwane.

Fakt, to jedno way/1158840547
było do usunięcia, bo wygląda na duplikat.

A to trzeba by przetagować: way/1157394377

2 pozostałe wyglądały poprawnie.

Cześć, dzięki zmianę, kilka drobnych uwag:
- jak "bot" zwrócił uwagę, do automatów paczkowych nie dodajemy `name`, nazwa się wyrenderuje na podstawie `ref` i `brand`.

- jeśli chodzi o `traffic_calming` na skrzyżowaniach, a rozumiem, że miałeś tu na myśli tzw. "skrzyżowanie wyniesione" to tu raczej `hump` nie pasuje, bardziej `traffic_calming=table`. W edytorze iD mogą być różne tłumaczenia pod to, z tego co widzę, to jest "Wyniesienie jezdni".

- jak kończysz prowadzić chodnik obok jezdni i nagle się urywa, to warto mimo to, go połączyć z jezdnią, a jak nie jest to możliwe to dodać `noexit=yes` na ostatnim niepołączonym węźle – kwestia routingu i walidacji niepołączonych ścieżek.
way/1210711301
way/1210711302

- way/1210711305 – to nie jest unclassified, wiem, że nazwa jest myląca bo dla nas brzmi kalkowo jak nieokreślona, ale to znaczy zupełnie coś innego. Drogi typu unclassified, to drogi rangi używanej do połączeń między np. miejscowościami w gminie, zdecydowanie ważniejsze niż lokalne residential. Najpewniej tutaj wystarczy zwykłe `highway=service`, chyba, że to podjazd do 1 posesji, to można dodać jeszcze `service=driveway`
osm.wiki/Pl:Tag:highway%3Dunclassified

Unclassified poprawiłem.

To nie jest dobre rozwiązanie. Lepiej już wrzucić w proposed:name=*, jeśli bardzo chcesz dodać nazwy, które dopiero będą obowiązywać. No i warto dorzucać źródło.

Chyba złą zmianę skomentowałem niedawno. O tę mi chodziło.

Zmiana jest bardzo dziwna, albo zawiera błędy.

Dlaczego np. w Komorowie/Pruszkowie refy są odwrotne względem peronów:

way/143567952

way/110258099

a w Grodzisku jest jakiś bardzo wysoki ref 2-cyfrowy?
way/1209095576

Nie sprawdzałem wszystkiego, tylko wyrywkowo.

Zmiana zawiera błędy, albo te dane są bardzo dziwne.

Dlaczego np. w Komorowie i Pruszkowie refy są odwrotne? W Grodzisku jest jakiś ref 2 cyfrowy.

Nie sprawdzałem wszystkiego tylko wyrywkowo.

Dzięki za zmiany w Kaniach. Drobna uwaga, usunąłem tę ścieżkę na Karolińskiej do Otrębus. Była już oznaczona obok i wyszedł duplikat.

Wyszło, że prom płynie przez 10 godzin:
route=ferry#Tags

Zmieniłem to tylko przy okazji, bo zostawianie takich niepołączonych fragmentów dróg nie pomaga. Nigdy nie wiadomo dlaczego ktoś tak to zrobił. Jeśli nie ma już stacji, można wycofać i przywrócić trawnik.

Warto przynajmniej dodawać `noexit=yes` jeśli nie są ze sobą takie drogi połączone, `oneway` pewnie też o ile nie możliwym jest np. zjazd z "dawnego wyjazdu".

Natomiast co do poprzedniej zmiany, to warto wrzucać w źródło "survey" lub/i inne na których się opierało, bo tak to inni mapujący nie wiedzą skąd, ktoś czerpie dane, tym bardziej, że zmiana wskazuje właśnie na użycie tylko i wyłącznie na zdjęć lotniczych. Pozdrawiam.

Uwzględniaj proszę inne tagi. Teraz jest sprzeczność, bo official_name nie jest oficjalne wg twojego źródła.

Przywróciłem residential. Nie wiem dlaczego zostało to zmienione na service.

Jakiś remont nakładki? Bo nie kojarzę w sumie, żeby jakaś większa przebudowa tu miała być robiona?

Trasy autobusów pewnie też nie zmieniali.

Oprócz tego dodawanie public_transport=platform do liniowych/obszarowych peronów, bo iD tak proponuje, czego w Warszawie nie robimy i było to komentowane już pod nie jednym zestawem zmian...

@ivanbranco, just report this vandal.

There is no sense to ask anything. Check more changesets comments or even only the latest one
(141059308).

*Wkleiłem pod pierwszą zmianą dotyczącą 63, ale się tyczy obu.

Cześć,
będzie dużo tekstu, więc zachęcam, żeby to wkleić do jakiegoś markdown preview online (np. https://stackedit.io/, lub https://pandao.github.io/editor.md), bo sformatowałem całość dla lepszej czytelności.

Na wstępie dzięki za dodanie linii 63, ale mam trochę uwag do zmiany:

1. Proszę postaraj się nie mieszać tyle rzeczy w zestawie zmian, tzn. zmiany przystankowe są oczywiste wraz drobnymi elementami typu dociągnięcie fragmentu chodnika do przystanku, czy coś, ale oprócz linii autobusowych widzę, że np. została tu również usunięcia ścieżka pieszo-rowerowa, nowe chodniki wzdłuż dróg serwisowych, ogólnie uszczegółowienia jezdni (to lepiej zrobić w oddzielnej zmianie i nie mieszać z samą relacją). To utrudnienia przeglądanie i weryfikację potem takich zmian.
Nie wiem, czy można to wygodnie robić w iD, ale do JOSMa stosuję taki myk, że jak znajdę taki obiekt co trzeba go poprawić, a nie powinien być w aktualnym zestawie zmian, to wciskam ctrl + shift + i, wtedy otwiera się w przeglądarce i nie musze o tym pamiętać i mapuję dalej :D
Przykład: way/812939028
A tutaj możesz sobie zerknąć jak wygląda ten zestaw zmian: https://nrenner.github.io/achavi/?changeset=141005569
A tak jeśli włączymy widok dotknietych relacji: https://nrenner.github.io/achavi/?changeset=141005569&relations=true

2. Prosze nie usuwaj liniowych `highway=platform`, tam gdzie nie jest to zasadne. W Warszawie i okolicach trzymamy się jednego standardu mapowania infrastruktury przystankowej. Głównie chodzi w nim o to, żeby w relacjach były `highway=bus_stop` i węzły na drodze stop postion, a `highway=platform` zarówno liniowe/obszarowe jest wtedy tylko "dodatkiem" wyznaczającym krawędź peronową. Nie jest to błędne i nie duplikuje danych, a jest to uszczegółowienie. W ten sposób jest przetagowywana cała Warszawa (głównie zajmuje się tym Tetryk). Oczywiście jeśli nie ma nic takiego, bo jest zwykły chodnik i słupek, to jest to zasadne, ale jak jest zatoczka/szerszy chodnik, to aż samo wskazuje, że można takie umieścić.
Przykład: way/283983907

3. Proszę nie dodawaj `public_transport=platform` do liniowych/obszarowych przystanków. O tym już pisałem pod inną zmianą. Wiem, że edytor `iD` to sugeruje, dlatego odradzam mapowanie nim relacji autobusowych, zdecydowanie lepiej to robić (subiektywna opinia) przez JOSMa, a jeśli chodzi o tylko i wyłącznie relacje, to można użyć narzędzia Northcraba Relatify (do nie skomplikowanych przypadków).
Przykład: way/196605790

4. Niestety relacja jest wymieszana, jest co najmniej 1 element przystankowy bez roli. W PTv2 kolejność ma znaczenie i jest dość wazna. Przyjmuje się, że powinno iść to tak:
`stop, platform, stop, platform`... (zaczynając od `*_entry_only`, kończąc na `*_exit_only` i potem kolejno odcinki drogi.
Zdaje sobie sprawę, że przez iD edycja tego to mordęga stąd odsyłam do sugestii z pkt nr 1 (inne edytory). JOSM ładnie wyświetla i pozwala w prosty sposób przenosić. Istnieje również plugin, który dla sporej liczby relacji sam je przesortuje (zawsze należy i tak sprawdzić).

---
**Tu już bardziej odnośnie samego tagowania i GPA.**

5. Czy moglibyśmy się trzymać standardu tagowania nazw? W Warszawie i okolicach zgodnie tagujemy nazwy relacji linii w następujący sposób:
`Bus 63: Warszawa P+R Aleja Krakowska => Grodzisk Maz. Dw. PKP`
Natomiast dla `route_master` wystarczy samo `Bus 63`.
Przykład warszawskiej linii:
- relation/3271602
- relation/3271646

6. Relacje GPA możemy wpiąć do sieci GPA (tylko `route_master`y). Znacząco to ułatwia śledzenie tego co jest zmapowane, a co nie oraz odnajdywanie się w tych relacjach.
Zaznaczę, że tylko część zweryfikowałem i poprawiłem dostosowując do powyższych standardów, głównie te co zmapowałem (przejeżdżające przez moje okolice): 60, 61, 62 oraz inne: 0, 10, 11 (nie pamiętam, czy 12 też). Reszta nadal wymaga przejrzenia i dostosowania, ale niestety nie mam na to wystarczjąco czasu.
Relacja sieci: relation/14262783

7. Wypadałoby, żeby `from` w relacji był taki sam jak w `name`, to samo się tyczy `to`. Byłoby w ogóle super, gdyby jeszcze to się pokrywało z tymi przystankami początkowymi/końcowymi (wykluczając ew. numerację), ale tu już wiadomo, że czasem różnie bywa.
W tym przypadku tak nie jest: `from=Grodzisk Mazowiecki Dworzec PKP` `name=63: Grodzisk Maz. Dw. PKP - Warszawa P+R Aleja Krakowska`

8. To już może być kwestia sporna, ale mam spore zastrzeżenia jeśli chodzi o tagi `operator`/`network`. Tzn `network` jest dla mnie ok, ale uważam, że wklejanie `Grodziskie Przewozy Autobusowe` jako operatora wszędzie nie jest poprawne z 2 powodów:
a) Same linie: GPA zaznacza wprost w niektórych rozkładach, że operatorami linii jest np. `PKS Grodzisk Mazowiecki`
b) Przystanki: Niektóre przystanki nie są wyłącznie słupkiem – są budowane na zlecenie gmin/powiatu, a nie GPA, więc zazwyczaj wtedy ten inny podmiot nimi zarządza. Czasem korzysta z nich więcej niż 1 sieć. Jak dla mnie wtedy urząd gminy jest operatorem takiego przystanku, ale to jest już własnie kwestia sporna, bo sam słupek pewnie operuje nadal GPA.

9. Drobna rzecz, literówka na wysokości Raszyna. Wyszła "Szkona", a nie "Szkolna".

10. Też drobna rzecz, poprosiłbym na przyszłość, żeby w źródle wrzucać jednak coś bardziej precyzyjnego tj. link do rozkładu :D To też ułatwia i czasem pozwala się z orientować kiedy był ostatni raz aktualizowany rozkład – czy trasa się nie zmieniła.