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

Witaj!
Zauważyłem, że w tym zestawie zmian złączyłeś obszary zabudowy mieszkaniowej przeze mnie podzielone. Uważam, że jest to niezbyt poprawne z trzech powodów:
1. praktyka dzielenia jest dozwolona zarówno przez polskojęzyczną wiki (osm.wiki/Pl:Użytkowanie_ziemi#Bardziej_szczegółowe_mapowanie_zagospodarowania_terenu), jak i anglojęzyczną (osm.wiki/Land_use#Mapping_land_use_in_more_detail);
2. drogi wzdłuż tych obszarów w głównej mierze tylko je obsługują, więc nie pełnią funkcji stricte mieszkaniowej, szczególnie, że są to drogi publiczne; taką funkcję mogą pełnić drogi na osiedlach bloków mieszkalnych (patrz: bloki przy Wojska Polskiego 52, 54 i 56 oraz przy Sienkiewicza 18A-24B);
3. granice obszarów są wyraźnie zaznaczone zarówno przez ogrodzenia, jak i koryto rzeki. Owszem, wymagały one doprecyzowania, jednak o wiele prościej było to robić na podzielonych obszarach.

Cześć!
Zerknąłem na Twoje ostatnie 3 edycje dotyczące dzielenia obszaru zabudowań i mam kilka uwag.

1. (dotyczy zestawu zmian nr 155210933, wzdłuż ulicy Wypoczynkowej)
Zostawiłeś niedomknięty duży obszar (way/226446606/history/25). Wystarczyło wydłużyć linię wzdłuż ulicy Drzymały, po węzłach obszarów przy Wypoczynkowej.

2. (dotyczy zestawu zmian nr 155211315, pierwsza wzdłuż ulicy Strumykowej)
Tutaj zrobiłeś podobnie: nie domknąłeś nowo utworzonego obszaru na południe od Parku Miejskiego (way/1307560335/history/1). Jeżeli chciałeś podzielić obszar w tym miejscu na mniejsze, powinieneś był poprowadzić linię po stronie południowej i wschodniej mniejszych obszarów.

3. (dotyczy zestawu zmian nr 155211710, druga wzdłuż ulicy Strumykowej)
Wygląda na to, że próbowałeś podzielić nowo utworzony mniejszy obszar po zachodniej stronie ulicy Strumykowej (way/1307561759) dodatkowo na mniejsze części. Zrobiłeś to niezbyt udolnie; połączyłeś linię z samą sobą. Tutaj podobnie: wystarczyło większy obszar (way/1307560335) wydłużyć wzdłuż wcześniej wspomnianego obszaru po jego południowej stronie.

Na Discordzie wysłałem Ci kilka zrzutów wyjaśniających.