> co do bram, to ich tu nie ma

Ok, to jeśli jest płot i nie ma bram, to należy uciąć te drogi i ich nie łączyć do Piaseczyńskiej. Urwać przed płotem (tak żeby się nie przecinało) i dać na końcu `noexit=yes`.

Jak te drogi kończą się przy tym 1 wjeździe, to jest to dla mnie OK jako track :)

> i raczej nie będzie zgodnie z Ustawą, zgodnie z której nie można już budować zamkniętych nowych osiedli.

Podrzucisz coś więcej w tym temacie? To jest coś lokalnego (jako uchwała), czy na poziomie krajowym? Nie słyszałem o tym wcześniej.

Ogólnie warto patrzeć na błędy, które walidatory edytora znajdują przed wysłaniem zmian, ale nie zawsze to co iD proponuje jest sensowne, prawidłowe, bądź konieczne.

Więc na to bym patrzył z przymrużeniem oka ;)

Dzięki za poprawę.

To zamknięcie to chyba troszkę przesadzone? :P

W sensie nie dodajemy aż tak krótkich zamknięć typu kilkudniowych.

Wiki niby podaje min. 6 miesięcy jako próg, choć to już dla mnie brzmi na zaszłość (bo są jednak aplikacje, które odświeżają często, a kiedyś niekoniecznie tak było).
Sam wyznaję min. te kilka tyg, ale tu wiem, że już różnie zależnie od mapującego.

osm.wiki/Pl:Key:construction

Zmiana na `highway=track` nie wygląda tutaj na poprawną – to droga o przeznaczeniu rolnym/leśnym.

Kategorie drogi nie są nadawane na podstawie nawierzchni. Od tego jest tag `surface`, a ta wygląda jak by pełniła funkcję dojazdu do osiedla przynajmniej do ostatniego wjazdu w Wieczorną, chyba że tak nie jest i to ślepy wjazd/wyjazd?

Zostały również usunięte bramy. Dlaczego? Czy dostęp do osiedla ma każdy? Jeśli tak, to należy zmienić access na drogach.

Cześć,
podjazdy to nie są przejścia dla pieszych :) Te tagi `highway=crossing` w miejscach przecięcia z `service=driveway` są zbędne.

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