Można dać tag `change=no`, który zabrania zmiany pasa ruchu
change=*

Można od biedy zmapować obszar `area:highway=emergency`, który nie będzie się renderował i w zasadzie za wiele nie wnosi, ale może spełni twoją chęć odwzorowania – tylko tu musi być dobry podkład z orto, wiec to by musiało trochę poczekać.

Ogólnie nie rozdzielamy jezdni jeśli nie ma fizycznych ciągłych barier.

Np. karetka, czy straż może spokojnie po takim obszarze wyłączonym pojechać.

Zmiana została wycofana, niestety zbyt dużo błędów.

Drogi zostały błędnie sklejone z granicami administracyjnymi zamiast drogą.

Nie równamy budynków do krawędzi dachu, tylko do ich podstaw/ogólnej bryły – przydatny tu jest EGiB.

W dodatku te adresy to w sporej części błędne duplikaty.

Nie rób takich wielkich zmian na przyszłość.

Cześć, podjazdy powinny być tagowane `highway=service` `service=driveway`, a nie `highway=track`

Nawierzchnia nie jest decydującym czynnikiem w kwestii wyboru typu drogi, od tego jest tag surface

Oprócz tego podjazdy muszą się przecinać z chodnikiem, nie ignoruj wszystkich ostrzeżeń edytora...czasem podpowiada sensowne rzeczy.

Ten znak znów się pojawił :/

Przywróciłem: changeset/173766429

Nie. Jest z kostki jak był :) Zmiana cofnięta.

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ć.