Please:
- do not remove addresses if they are still visible on the Geoportal address layer or added from another verifiable source
- change `source:building`/`source:geometry` or other source tag if you are changing shape or tags
- do not align to Bing – it is not primary imagery in Poland. Geoportal Ortophotmap is. The Bing imagery is also slightly offset. For buildings, we use EGiB (Ewidencja Gruntów i Budynków) overlay.

Czym jest legacy=1 i dlaczego masowo to dodajesz?

Znacznie lepiej. Dzięki!

> A co do "prefiksów cyklu życia"

Nie do końca rozumiem przesłanie tej odpowiedzi. Mogę zachęcić do ponownego przejrzenia wiki w tej kwestii, bo brzmi dokładnie jak przypadek tego użycia.

Rozróżnienie między tagowaniem `construction`/`proposed` dla wybranych kluczy jak najbardziej istnieje. Na zasadzie, że nie tagujemy `construction:building=*` tylko `building=construction`. Głównie w to się wlicza `highway`, `building`, `railway`, `landuse` – ale to też nie jest takie oczywiste, bo każde ma swoje wyjątki dla `proposed`/`construction`.

Czasem i tak użycia łamiące te zasady się zdarzają w szczególny przypadkach i jak najbardziej mają wtedy sens.

Na wiki znajdziesz przykład, który akurat w miarę tu pasuje, co prawda o torach, ale też prefiksem

`construction:electrified`
osm.wiki/Lifecycle_prefix

Rozbieżności między wersjami bywają. Zawsze lepiej czytać ang. wersję, chyba że rozbieżność wynika z innego przyjętego lokalnego tagowania np. adresy.

Co do dmuchania na zimne – to zwyczajnie takie tagowanie nie zezwala, żeby tymi odcinkami nawigować.
Na polskim podesłanym wiki też jest fragment o tym, że można opcjonalnie dorzucać foot=yes/bicycle=yes, aby nadpisać zakaz poruszania z powodu budowy, co potwierdza, że tak to może być interpretowane.

Ja wiem, że jest to ciut więcej roboty, ale jeśli wkładamy wysiłek w mapowanie czegoś na etapie proponowanym/budowy, to warto minimalizować jakiekolwiek nieścisłości.

Tagowanie nie jest w OSM super oczywiste/spójne, ale jak chcesz jeszcze inne przykłady, kiedy to powyższe się sprawdza to zmiana np. zmiana z proposed na construction to podmiana jednego słowa `construction`. Jak dodasz `construction:lit=yes` to bardzo często jest tak, że ścieżka bywa przejezdna, ale oświetlenie jeszcze nie działa, wtedy trzymanie `lit=yes` bez prefiksu jest również nieprawidłowe, trzeba by ew. trzymać `lit=no` z jakimś `note`, więc ogólnie pozwala na zmiany częściowe.
Czasem bywa tak, że chodnik jest zmieniany na CPR, wtedy też się przydaje do proposed kiedy chodnik cały czas funkcjonuje.

> OK, a co do `construction:klucz=wartość`, to poproszę o link do Wiki OSM, bym nie miał wrażenia, że to opinia jednego edytora.

Nie upieram się przy tym konkretnym tagowaniu, wskazuję tylko problemy wynikające ze stosowania powyższego.

Ja takie stosuje, bo gdzieś takie podpatrzyłem, trochę użyć znajdziesz np. tutaj: https://taginfo.openstreetmap.org/keys/construction%3Abicycle#overview w myśl zasady ATYL/użycia prefiksów cyklu życia obiektu.

Inna opcja to niedodawanie w ogóle na etapie budowy żadnych access'ów i np. `note`, które zawiera coś w stylu, że to będzie CPR segregowany itp. tylko jeśli można napisać w note, to można i innymi tagami to wyrazić szczególnie takimi, które można łatwo zmienić chwila moment.

Mi zależy na budowaniu świadomości dlaczego takie coś może stanowić problem, a raczej to jest coś co chcemy uniknąć popularyzując mapy.

Zalinkowane wyżej do innej zmiany z uzasadnieniem.

Aplikacje mogą różnie podchodzić do nawigacji przy mieszaniu tagów dostępu.
Lepiej minimalizować ryzyko, że ktoś zostanie przez to nawigowany.

Np. tutaj wiki sugeruje, że przy `highway=construction` klucze powiązane z `access` takie jak `foot`, czy `bicycle` mogą nadpisywać domyślne dostępy wynikające z samego `construction` co ma dużo sensu np. przy dodawaniu `access=destination` (jak dojazd do posesji) w trakcie budowy no i ogólnie są też bardziej precyzyjne hierarchicznie.

highway=construction#How_to_map_the_start_of_a_road_repair_or_reconstruction

Oprócz tego `public_transport=platform`też warto zmienić na `highway=platform`. Najlepiej liniowe, o ile jest tam zatoczka/wydzielony niewielki fragment peronowy, a jeśli nie ma nic takiego to najlepiej nie dawać w ogóle.
`public_transport` jest zbędnym duplikatem, bo jest już na węźle.
Ta idea się wpisuje w standard warszawski (i nie tylko).

Ponownie brak źródeł + nieprawidłowe tagowanie:

changeset/172569571#c1492423

2. Nie wolno tak robić!
Nie usuwamy całości z myślą zostawienia na później.
Jak w tym momencie teraz ktoś pobierze dane to zostanie na lata pusty obszar, a tak się realnie dzieje.

I obszar jest jak najbardziej do przywrócenia, bo teraz to jest biała plama.

1. Lepiej robić kawałek po kawałku, przesuwając/tnąc, a nie usuwając całość.
A tak w ogóle to jak się bawisz w residentiale, to polecam JOSMa, tam są super narzędzia do cięcia takich obszarów bardzo wygodnie (np. alt + x), no i zapisywać zmiany lokalnie (bez wysłania) też możesz, ale zawsze jest ryzyko, że ktoś narobi konfliktów i ogólnie mniejsze zmiany są zazwyczaj rekomendowane.

Trzeba naprawdę być smutnym człowiekiem, żeby psuć dane OSM, zamiast zapytać społeczność, jak można rozwiązać problem w swojej aplikacji...

Dlaczego wciąż próbujesz to błędnie zmieniać?

Zrozum, że jeśli masz jakąś swoją aplikację, to w niej musisz to obsłużyć, a nie psuć dane OSM.

note/4945061

Mam wątpliwości co do uwagi, bo brzmi jak nazwa opisowa, ale jak piszesz, że na pewno poprawne to podrzucam, bo może jesteś w stanie to potwierdzić/zaprzeczyć.

A jak chcesz "wymusić" rendering to można zmapować właśnie zieleń (trawniki) z BDOTu, która otacza te chodniki, przez co same kolory zieleni i parku lekko kontrastując wytworzą "tory" chodnikowe.
Takich przykładów też znajdziesz trochę w Warszawie i innych miastach.

Jest jak najbardziej zaakceptowany, co widać przez to, że jest używany i nie został oznaczony jako przestarzały. Nie każdy tag musi zostać przegłosowany żeby był w użytku.

Oczywiście sporo mapujących za nim nie przepada (ja również z kilku powodów), ale jest to akceptowalne rozwiązanie, które pozwala na mapowanie obszarowe chodników/ścieżek + innych obszarów m.in. właśnie w takich miejscach jak parkach – gdzie ktoś chce zmapować konkretnie obszar nienaturalny, a nie wystarcza choćby zmapowanie zieleni obok.

Natomiast mapowanie obszarowe chodników jest dość kontrowersyjne i zwykle zarezerwowane dla większych placów/przestrzeni, a tu dostatecznie dobrze wyznaczają to linie.

Dodatkowo to duplikuje w ten sposób przebiegające highway, a trochę nie o to w tym chodzi – nie ma potrzeby to reprezentacji sporej pustej przestrzeni, bo jej tu nie ma.

Odpowiedz sobie na proste pytanie, czy zmieniłbyś to na `highway=footway`, gdyby się nie renderowało?

Jak dla mnie jest to do cofnięcia i `area:highway` do przywrócenia.

Z podobnych sytuacji możesz zaobserwować to np. w Warszawie w Parku Skaryszewskim, gdzie bywało to wycofywane wiele razy na przestrzeni lat.

Dlaczego przywracasz ponownie ten highway=footway? area:highway było poprawne, a to wygląda mapowanie pod wymuszony render.

Ok, czyli nie twój survey.

Pytam, bo różnie samą uwagę różnie można interpretować i tak szybko bym jej nie zamykał. W okolicy większość kiosków jednak dalej stoi, nie działają, ale stoją i wtedy warto go dodać.

Byłeś tam dziś? Bo warstwy sugerują zupełnie co innego?

way/1074290098

Przejazd na ulicy z kostki stał się asfaltowy?

A nie widziałem, już odpowiadam.

Zaktualizowałem tagowanie Olejomatu – kilka już ich dodałem :P

Dzięki za dodanie i zlinkowanie zdjęcia!