junction=roundabout zamiast oneway=yes

Dlaczego likwidacja?

t's probably the incorrect name of the restaurant. Do you know the correct one?

Zmiany organizacji ruchu na 1 dzień, 4 dni przed to przesada.

Proszę nie rób tak na przyszłość, to nie pomaga.

Tak krótkich zmian wynikających z powodu np. święta, marszu/maratonu, czy innego tego typu krótkotrwałych wydarzeń nie mapujemy.

Reverted: changeset/143172538

Currently, the track is unused. Please verify more carefully source's you use.

WKD plans to restore it on 2024-01-01.

Faktycznie. Wygląda na to, że mają rozbieżność w danych urzędowych.

Wysłałem pismo do urzędu. Dam znać jak dostanę odpowiedź.

Szkoły to ciężki temat, tu akurat panują "rożne zwyczaje" w zależności od miasta/gminy jeśli chodzi o nazewnictwo, bo również czego innego oczekują "lokalsi" np. w jednych miastach numeracja ma olbrzymie znaczenie, w innych tylko patron, a w jeszcze innych obie informacje są pożądane ze względu choćby na duplikaty. Faktycznie "Warsaw Bilingual School Dwujęzyczna Szkoła Podstawowa im. prof. Władysława Bartoszewskiego" można rozważyć do skrócenia, przeniesienia części do np. `name:en` itp.

> Wojewódzki Ośrodek Ruchu Drogowego w Warszawie ME1 - Odlewnicza

Faktycznie się tu duplikują w różnych wariantach. Można rozważyć usunięcie np. z obszaru, bo nie musi tego mieć.

> Miejsce Egzaminowania 3 'Radarowa'/Sala egzaminów teoretycznych

Też wygląda słabo, ogólnie to powinno być raczej w description niż name.

> Szkoła Podstawowa nr 33 im. Wojsk Obrony Powietrznej Kraju

Tak, faktycznie też do poprawy.

Ogólnie część powyższych poza tą szkołą dwujęzyczną to zaszłości np. ta szkoła nr 33 to zmiana sprzed 10 lat :)

> Licea są numerowane, na przykład IIXV, ale są one po prostu oznaczone jako nr 23.

Pominę dalszy temat szkół, bo tu trwają importy (temat rozwojowy), nie do końca jest zgodność, stąd niektóre wyglądają tak, a nie inaczej, nie chciałbym się w tym temacie za bardzo wypowiadać, bo nie mam w nim wystarczającej wiedzy.

> Każda mapa wydaje się kłaść nacisk na prawdziwe informacje, a nie na te, które komuś się podobają.

Zgadza się, ale skrócona nazwa temu nie przeczy, bo pełne dane są wciąż zachowane :)

> Wydaje mi się, że tutaj powinno być tak samo.

No z tym różnie bywa. Klucz name jest dość często tematem dyskusji, własnie z tego względu, że to co się w nim znajduje jest zazwyczaj wyświetlane. Nazewnictwo to ogólnie bardzo ciężki temat. Jak pogodzić przejrzystość, ze spójnością z zachowaniem wypracowanych zasad przez społeczność i żeby jeszcze użytkownik dodający był z tego zadowolony.
Na pewno nikt nie jest tutaj złośliwy i nie ma tego na celu.

----

> skracanie nazw prowadzi do problemów z lokalizacją lub identyfikacją obiektów w aplikacjach korzystających z map.

I tak i nie, w tym przypadku nie powinno, bo możemy wrzucić nazwę do official_name/alt_name. Jak by było tylko samo "Marleen" i nigdzie w tagach pełnej nazwy, to bym się zgodził z tym stwierdzeniem. Oprócz tego przetwarzane są również tagi obiektu, one też dają pewne podpowiedzi. Nie wszystko jest bazowane na nazwie.

> Pełne i dokładne nazwy obiektów umożliwiają jednoznaczną identyfikację i ułatwiają użytkownikom znalezienie poszukiwanych informacji. Jeśli obiekty mają skrócone lub niejednoznaczne nazwy, może to utrudnić nawigację i wyszukiwanie

Jeśli nazwa jest w innym kluczu, również jest uwzględniana przy wyszukiwaniu choćby na głównej stronie (Nominatim). Przykład użycia old_name, bądź loc_name "Park Zachodni" (aktualnie Park Pięciu Sióstr"), wiec nie ma z tym żadnego problemu (może trochę potrwać zanim wyszukiwarka zaindeksuje zmianę – nie działa to natychmiast).
official_name i alt_name też są wspierane, wcześniej wymieniłem full_name, ale do tego nie mam pewności.

Można spokojnie wrzucił pełną nazwę w official_name, czy alt_name, a tą krótszą trzymać w name.

Co do jeszcze opisu zmiany:
> żaden sposób nie można jej identyfikować z naszym salonem.

Pozwolę sobie wrzucić wcześniejszą zmianę, w której opisie znajdują się 2 linki, które zawierają samo "marleen" :D
changeset/135075898

-----
Co do innych drobnych rzeczy:

addr:country, nie dodajemy w Polsce do adresów

Tag beauty ma nieprawidłowe wartości – nie mieszamy zwykle polskich wartości z angielskimi. Zdarzają się "regionalne tagi", ale ten do nich nie należy.

Nazwę oficjalną można wrzucić do tagu `official_name` , `full_name`, czy też `alt_name`. W OSM tag name nie zawsze musi być zgodny z nazwą urzędową – często tak nie jest, więc link do ceidg nic tutaj nie zmienia.

Ta nazwa jest po prostu bardzo długa, zawiera sporo wielkich liter, które nie stanowią powszechnie używanego skrótu (np. KFC, czy H&M) i zakłóca czytelność innych obiektów w okolicy.

Ta informacja w żaden sposób nie jest utracona, bo to samo aktualnie jest w tagu operator, ale również uważam, że poprzednia nazwa "Marleen" jest tutaj lepsza. Można oczywiście wrzucić do powyżej wymienionego tagu zamiast operator.

Bo było błędnie dodane obok i powstały 2 Corrado :P Ale dzięki za wyłapanie.

Odpowiadając: to jest jak najbardziej restauracja – mają całkiem dobre "normalne" dania.

Poprawiłem i zaktualizowałem: changeset/142774390

Poprawiłem tagowanie, uzupełniłem informacje ze strony i przeniosłem na węzeł:

node/11260918161

Skąd informacja, że to jest Skwer im. Józefa Piłsudskiego?
Geoportal wskazuje na Park Anielin jako poprawną lokalizację (nazwa alternatywna), co z resztą jest już zmapowane.

Odpisałem pod pierwotną zmianą (141812647)

Ok, to 2 sprawy:
1. Aktualnie to jest jedyna możliwość, więc taka relacja jest zbędna, bo reszta wynika z aktualnego stanu tagowania na skrzyżowaniu (nie da się pojechać ani prosto, ani w lewo, bo jezdnia jest jednokierunkowa). Można to oczywiście podkreślać, ale nie widzę sensu, bo w routingu to nic nie zmieni, chyba, że to ma być nowa organizacja ruchu (po zakończeniu przebudowy).

2. Relacja nakazu skrętu, aby była prawidłowa musi posiadać min. 3 elementy z rolami:
- from – way z którego zaczynamy
- via – punkt skrzyżowania bądź way będący jego fragmentem (np. na zawrotkach)
- to – way jezdni docelowej
Ta powyższa nie miała żadnych ról i był tylko 1 element – nie wiadomo czego dotyczyła, więc mogło chodzić równie dobrze o Sandomierską, czy podjazd do terenu MON.

osm.wiki/w/index.php?title=Relation:restriction&uselang=pl

Edytor iD posiada wbudowany komponent do tworzenia restrykcji na skrzyżowaniach, jeśli tego używałeś i coś poszło nie tak, to może warto im to zgłosić na githubie.

Pytam z tego względu, gdyż na e-mapie jest po prostu inaczej, a jako, że adresy to twór tylko i wyłącznie urzędowy (niezależnie od tego co właściciel wywiesi w terenie), każdą taką sprzeczność wypadałoby wyjaśnić bezpośrednio z urzędem.

Akurat w Piastowie kilka adresów naprawili, które kiedyś zgłosiłem więc i tu pewnie warto podesłać i opisać sytuację.

https://piastow.e-mapa.net?userview=168

To nie jest dobry argument.

Jaka nawigacja?
Może warto używać innej w takiej razie?

To zewnętrzne oprogramowanie powinno się dostosować do tagowania OSM, a nie my do zewnętrznego oprogramowania.

Coś nie wyszło z ta relacją – jest nieprawidłowa. Jaki był cel tej zmiany?

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)