Witaj!
Twoje 3 ostatnie zmiany budzą wątpliwości poważniejsze niż 2 poprzednie. Dodanie nieistniejącej drogi do Pionek, zmiana nazwy Działek Suskowolskich czy usunięcie drogi serwisowej przy centrum M Park to jawny wandalizm i zostanie on wycofany. Jednocześnie ostrzegam polską społeczność OSM, aby zwróciła na Ciebie uwagę; następny taki czyn zostanie zgłoszony Grupie Roboczej ds. Danych (Data Working Group) OSM Foundation.
Z wyrazami szacunku
Kamil Kalata

Witaj!
Przejrzałem 2 Twoje ostatnie zmiany i mam kilka uwag.
Są zmiany, które są wykonane w miarę poprawnie, na przykład dodanie Żabki, poprawa lasu przy Alei Jagiellońskiej czy dodanie chodnika przy bloku przy Asnyka 2. Są też zmiany wątpliwe, jak na przykład zmiany dróg na lokalne (highway=residential). Są też zmiany niedopuszczalne, jak na przykład oznaczenie Pionek jako place=city (w Polsce tym tagiem są oznaczane miasta na prawach powiatu), zmiana granic administracyjnych czy usunięcie miejscowości.
Ze względu na przewagę zmian złych nad dobrymi jestem zmuszony wycofać wszystkie Twoje dotychczasowe edycje. Na przyszłość polecam dokonywać mniejszych, ale częstszych zmian oraz opisywać je według tego, co zostało zmienione.
Z wyrazami szacunku
Kamil Kalata

Witaj!
Cieszę się, że postanowiłeś dołączyć do projektu OpenStreetMap! Niemniej jednak muszę zwrócić Tobie uwagę na kilka błędów, które, niestety, popełniłeś:
- przy Kauflandzie dodałeś nowy parking (way/1457773369) na obszarze już istniejącego;
- dodałeś Centrum AA (way/1457773370) jako nowy budynek; wystarczyło poprawić już istniejący (way/303167976);
- przesunąłeś punkty skrzyżowań ulic Kiepury i Kilińskiego (node/2565263422) czy 1 Maja, Spółdzielczej i Odrowąża (node/683180402), a także dokonałeś paru zmian przy skrzyżowaniu ulic Wjazdowej, Starowarszawskiej i Targowej (osm.org/#map=19/51.193202/20.406909), w związku z czym popsułeś ich układ;
- skwerek na Placu Kościuszki (way/1457773364) stanowi część tego placu (relation/18144174), w związku z czym nie należało go tworzyć; podobna sytuacja jest z Parkiem Małachowskich (way/1457773365) czy Ogródkiem Jordanowskim (way/1457773366);
- bankomat przy ulicy Piłsudskiego (node/13369482947) budzi moje wątpliwości; oznaczyłeś go jako bankomat banku "santander" (sic), ale, po pierwsze, nie widzę żadnej informacji na stronie Santandera, a po drugie, gdyby to był bankomat tego banku, to mogłeś po prostu zatwierdzić propozycję edytora, klikając "Uaktualnij te znaczniki"; przy obecnym tagowaniu można pomyśleć, że bankomat został uruchomiony przez firmę podszywającą się pod Santandera;
- z tego, co widzę na ortofotomapie, to to, co oznaczyłeś jako park (way/1457773367), jest siłownią na świeżym powietrzu; do takich obiektów jest specjalny tag: leisure=fitness_station.
Niestety, ale będę musiał wycofać większość Twoich zmian. W razie wątpliwości, poszukaj informacji na stronie wiki (osm.wiki) lub zadaj pytanie na forum, w sekcji "Pytania początkujących" (https://community.openstreetmap.org/t/pytania-poczatkujacych/52707) czy serwerze Discord "OSM Polska" (https://discord.com/invite/QxNfsJ9T).
Z wyrazami szacunku
Kamil Kalata

Witaj!
Byłem zmuszony wycofać zmiany "ułatwiające dojazd przy użyciu aplikacji e-Remiza", gdyż, wbrew pozorom, wcale nie ułatwiały tego zadania. Przede wszystkim, nastawnia już była oznaczona jako nastawnia, a jej oznaczenie jako tory kolejowe pogorszyło stan mapy. Ponadto, została popsuta geometria elementów (np. błędnie przekrzywione linie), a także nadano elementom nazwy opisowe, czego nie powinno się robić (osm.wiki/Pl:Nazwy#Nazwa_jest_tylko_nazwą).

Dzień dobry.
Z przykrością stwierdzam, że musiałem wycofać tę zmianę, ale zawierała poważne błędy:
- zostały przesunięte punkty związane z Nowym Światem i chodnikiem znajdującym się w jego pobliżu;
- poradnia została dodana na całym bloku, zamiast jako osobny punkt znajdujący się wewnątrz niego (jednocześnie radzę, żeby w już poprawnej zmianie numer mieszkania dodać w znaczniku addr:unit).

Witaj!
Chciałbym zwrócić Tobie uwagę na zmianę tagu "destination". Na jezdni w kierunku Kozienic dodałeś miejscowość, której na znakach przed Rondem Kozienickim nie ma (konkretniej Pionki). Nie powinno się tak robić, mimo że ta droga prowadzi w stronę tej miejscowości, z wyżej podanej przyczyny. Podobnie zrobiłeś 5 lat temu na jezdni w kierunku Warszawy (Michałów, Centrum (drogowskaz dotyczy wyłącznie lewoskrętu na Żółkiewskiego w stronę Kozienickiej)) i Lublina (Zwoleń, Puławy), 6 lat temu na łącznicy wjazdowej przy Alei Wojska Polskiego w kierunku Ronda Kozienickiego (Grójec) czy miesiąc temu na rondzie w Tczowie na jezdniach w kierunku Podgóry (Radom, Pionki) oraz Kazanowa (Lipsko) (w sprawie ostatniego przypadku proszę o potwierdzenie, ale śmiem wątpić, że nadmiarowe miejscowości pojawiły się na drogowskazach).
To, że miejscowość prowadzi w danym kierunku, nie oznacza, że tag "destination" powinien go zawierać. Nawigacja powinna wybrać drogę jak najkorzystniejszą dla podróżującego na podstawie hierarchii drogi i jej parametrów, a nie zawartości tagu "destination", który i tak jest niezgodny z opisem rzeczywistości, a dokładniej z treścią drogowskazów. Ponadto, nawigacje korzystają z tego tagu i wyświetlają podróżującemu jej zawartość, a rozbieżność między danymi w OSM a rzeczywistością może wywołać u niego poczucie zagubienia.

Witaj!

Zauważyłem, że zapomniałeś dodać do relacji obszaru wyłączonego z ruchu (relation/10889748) tagu type=multipolygon. Błąd ten poprawiłem (changeset/162245528). Gdybyś miał jakieś uwagi, skomentuj mój zestaw zmian lub zgłoś je w wątku na OSM Community (https://community.openstreetmap.org/t/review-relations-with-no-type-tag/125062).

Witaj!

Zauważyłem, że chciałeś zapewne usunąć zbędną relację type=multipolygon, z której chwilę wcześniej usunąłeś ten tag (relation/2534481), lecz ostatecznie tego nie zrobiłeś. Błąd ten poprawiłem (changeset/162212252). Gdybyś miał jakieś uwagi, skomentuj mój zestaw zmian lub zgłoś je w wątku na OSM Community (https://community.openstreetmap.org/t/review-relations-with-no-type-tag/125062).

ref:ckkp to identyfikator Cyfrowego Kanonu Krajoznawczego Polski, za którego opracowanie odpowiada Stowarzyszenie OpenStreetMap Polska (https://openstreetmap.org.pl/2024/cyfrowy-kanon-krajoznawczy-polski-bedzie-opracowywany-przez-osmp/).

Witaj!
Łączniki przez Ciebie dodane, wbrew Twojej argumentacji, właśnie łamią zasady opisane na wiki. Przede wszystkim, prawoskręty są oddzielone tylko powierzchnią wyłączoną z ruchu, a nie wysepką, więc nie ma fizycznej separacji. Jako że rondo to tylko skrzyżowanie o ruchu okrężnym, odnosi się do niego ta zasada: osm.wiki/Pl:Highway_link#Skrzyżowania_jednopoziomowe. Przykład niżej podany w sekcji o rondach (osm.org/#map=19/50.683270/17.386980) wyróżnia się właśnie takim rozdzieleniem. Ponadto, anglojęzyczna wiki (osm.wiki/Highway_link#Roundabouts) doprecyzowuje podaną regułę w odniesieniu do rond.

Rozumiem Twój argument, ale:
1) zostało ustalone, żeby highway_link=*, podbijać do wyższej kategorii (osm.wiki/Talk:Pl:Znakowanie_dróg_w_Polsce#Węzły_drogowe_-_GŁOSOWANIE); ponadto widzę, że poparłeś takie rozwiązanie;
2) łącznik ten można wykorzystać jako zawrotkę; ten kontrargument może normalnie nie jest kluczowy ze względu na zawrotkę za Międzynarodową, ale jest ona zamknięta, a ponadto zawsze można zawrócić na tym łączniku.

Cześć!
Uważam, że zmiana na highway=secondary_link jest niesłuszna, gdyż można za tym fragmentem wjechać na drogę highway=primary_link, która kończy się na highway=primary, więc mamy tu do czynienia z bezsensowną zmianą hierarchii drogi.

Tag access=permissive znaczy, że droga prywatna jest de facto dostępna dla ogółu, ale może to być zmienione w każdej chwili bez ostrzeżenia. W tej sytuacji właściwszym tagiem jest access=permit lub access=private (drugi ma bardziej restrykcyjne zasady wydawania pozwoleń).

Renderowanie altanek na prywatnych posesjach to już problem tej warstwy, nie danych. Anglo- i polskojęzyczna Wiki dopuszczają ich mapowanie; wystarczy dać tag access=private. Styl OSM Carto (warstwa podstawowa) zwraca na niego uwagę i wyszarza takie altanki.
Przypomnę swoje zastrzeżenie z wcześniejszej takiej zmiany (changeset/156945582): tagujesz pod render, co nawet podajesz jako powód zmiany, a czego nie powinieneś robić.

Argumentacja stojąca za tą edycją kwalifikuje ją jako tagowanie pod render, co jest błędną praktyką. Altanki przez Ciebie zmienione poprawiłem (changeset/156946250).

Dobrym rozwiązaniem byłby komentarz w stylu "Radom, Janiszpolska - mikromapowanie". Może nie jest on wyczerpujący, ale o wiele bardziej precyzyjny, niż "drobne korekty".

Kwestia ta była omawiana tutaj: changeset/155492710

Witaj!
Przejrzałem Twoje edycje związane z hydrantami i mam kilka zastrzeżeń dotyczących tagowania:

1a. colour=czerwony (powinno być colour=red)

1b. colour=- (myślnik) (nie powinno być tego tagu)

2. couplings=x2 (pewnie miałeś na myśli couplings=2)

3. fire_hydrant:diameter=80.0 (wartość poprawna, ale można uprościć do 80)

4. ref=- (myślnik) (nie powinno być tego tagu, chyba że jesteś całkowicie pewien, że hydranty nie mają numerów identyfikacyjnych, wtedy noref=yes)

Dzień dobry.
W imieniu społeczności OpenStreetMap dziękuję za dodanie biura rachunkowego. Znalazłem jednak kilka błędów:
1. takie biura powinny być oznaczane "office=accountant" (osm.wiki/Tag%3Aoffice%3Daccountant, osm.wiki/Pl:Tag:office%3Daccountant);
2. opis (w tagu "description") nie powinien stanowić reklamy; kwestia ta była ostatnio poruszana (https://community.openstreetmap.org/t/getpin-automatyczna-edycje-pko/114423);
3. słowa kluczowe (w tagu "information") spełniają podobną funkcję; ponadto wspomniany tag służy określeniu rodzaju informacji turystycznej (osm.wiki/Key%3Ainformation, osm.wiki/Pl%3AKey%3Ainformation);
4. godziny otwarcia zostały błędnie oznaczone w postaci "godziny otwarca=poniedziałek - piątek 8:00-16:00"; prawidłowym sposobem jest "opening_hours=Mo-Fr 08:00-16:00"; przydatnym narzędziem jest ta strona: https://openingh.openstreetmap.de/evaluation_tool.

Witaj, Piotrze!
Z Twojej argumentacji wynika, że dążysz do maksymalnego upraszczania mapy. Rzeczywistość jest jednak bardziej złożona i myślę, że należy ją przedstawiać taką, jaka ona jest.
Pozwól, że przedstawię swoje opinie na Twoje dylematy:

Ad. 1.
Tu po części się zgadzam, ale z innego powodu: większość węzłów obszarów była ułożona niemal równolegle (z dokładnością do nawet kilku centymetrów) i można ich było nie tworzyć. Jednak co do programów nawigacyjnych mam wątpliwości. Dobrze zoptymalizowany program powinien mniej priorytetowo traktować landuse'y, np. poprzez przesortowanie danych w preprocessingu, dzięki czemu poziom uszczegółowienia obszarów nie będzie korelował ze złożonością czasową przetwarzania bardziej wartościowych danych. Jeżeli chodzi natomiast o zasoby pamięci, to należy mieć z tyłu głowy prawo Moore'a; prędzej czy później obszary byłyby w ten sposób uszczegółowione bez większego wpływu na dość nowy sprzęt, a dane na starszy mogłyby zostać pod tym kątem zoptymalizowane, dzięki czemu funkcjonalność tego nowszego nie byłaby upośledzona.

Ad. 2.
Owszem, Zwoleń ma taki charakter, jednak, moim zdaniem, taki wniosek powinien zostać wysnuty na podstawie analizy powierzchni obszarów i stwierdzenia na jej podstawie, że zabudowa mieszkaniowa pełni rolę dominującą, niż na podstawie "rzucenia okiem", co by było mało precyzyjne. Ponadto, idea wysepek kłóci się trochę z "ground truth", np. obszar stricte usługowy, który nie pełni funkcji mieszkaniowej, byłby oznaczony jako landuse=commercial na większym landuse=residential, co by oznaczało, że teren ten spełnia dwie funkcje, a nie powinno się przyjmować założeń, że mniejszy obszar całkowicie zastępuje ten większy.
Utożsamianie landuse=residential z obszarem zabudowanym według PoRD mija się trochę z celem, gdyż zabudowa mieszkaniowa może występować poza obszarem lub obszar w miejscu niezamieszkanym, co jest jednak przez prawo odradzane, ale samo to oznacza, że może tak się stać. Ponadto, są to osobne byty; obszar z PoRD należałoby otagować traffic_sign=city_limit, maxspeed=50 i source:maxspeed=PL:urban.

Ad. 3.
Fakt, miałem z tym problem, jednak biorąc pod uwagę błędną wówczas geometrię budynków, postanowiłem przecinać budynki z landuse'ami (swoją drogą, dzięki za wykonanie dobrej, rzekłbym nawet brudnej, roboty w postaci korekty geometrii i danych adresowych, dzięki czemu łatwiej będzie ten problem rozwiązać). Uważam jednak, że prędzej czy później ten problem by się pojawił, zważywszy, że praktyka dzielenia jest dozwolona, chyba że mapujący by od razu kleił landuse'y z budynkami.

Ad. 4.
Co do obszaru drogi, to jest na wiki propozycja landuse=highway, co oznacza, że mapę można uszczegółowić jeszcze bardziej.
Co do rozbijania, drogi i rzeki stanowią niezbyt łatwe do przekroczenia bariery; przez rzekę trzeba przeskoczyć, a przez drogę, szczególnie ruchliwą, przejść lub włączyć się do ruchu na niej. Ponadto, są one dodatkowo uregulowane (rzeki przez Prawo wodne, drogi przez PoRD), co wyłącza dowolność zagospodarowania terenu. Jedynymi miejscami, w których nie rozdzielałbym landuse'ów, byłyby takie, w których te bariery stanowią integralną część i nie sposób stwierdzić, w których miejscach stanowią one rozgraniczenie, np. rzeki płynące przez parki czy drogi na osiedlach bloków.

Moim zdaniem, Twoje dylematy są raczej problemami wieku dziecięcego, jako że kilka lat temu maperzy dążyli do jak najwierniejszego zobrazowania rzeczywistości jak najmniejszym kosztem. Jednak, im bardziej projekt OpenStreetMap staje się dojrzały, tym większa presja na uszczegółowienie danych. Nie bez przyczyny niektórzy podnoszą z tego powodu larum (note/2649130) (swoją drogą, duży landuse=residential w Zwoleniu był zmapowany właśnie przez rosomaka). Ponadto, rozcinanie obszarów to wstęp do mikromapowania, co możesz zaobserwować na ulicy Reja, a także do łatwiejszej edycji w przyszłości (mniejsze bboxy zestawów zmian, mniejszy obszar oddziaływania potencjalnych błędów).

Z wyrazami szacunku
Kamil Kalata