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.

Witaj!
Mam drobną uwagę do łącznika: według strony na wiki (osm.wiki/Pl:Dobre_praktyki#Nie_u%C5%BCywaj_tagu_name_do_opisywania_rzeczy) nazwa jest niepotrzebna.

Witaj!
Zauważyłem, że zmapowałeś ostatnio obszary podjazdów i chodników jako place=plot. Dokumentacja na wiki (place=plot, osm.wiki/Pl:Tag:place=plot) podaje, że tym tagiem powinna zostać oznaczona cała działka, a nie tylko jej fragment. Ilustracja ta (osm.wiki/File:Lot_map.PNG) całkiem dobrze to ilustruje; działką jest obszar wewnątrz grubej czarnej i czerwonej linii. Jeżeli chcesz kontynuować tę praktykę, polecam stosować tag area:highway=*.

Zmiana została wycofana (powód: brak konsensusu) (patrz: changeset/153868403)

Zmiana została wycofana (powód: brak konsensusu) (patrz: changeset/153864937)

Zmiana została wycofana (powód: brak konsensusu) (patrz: changeset/153864665)

Kilka uwag co to Twoich zmian:

1. Tutaj (way/358045265) i tutaj (way/846578667) ustawiłeś wartość "maxweight=2,5 t". Zgodnie z przyjętymi zasadami (maxweight=*) rolę separatora dziesiętnego pełni kropka, a domyślną jednostką masy jest tona, w związku z czym wspomniane drogi powinny być otagowane "maxspeed=2.5".

2. Drogi na Rynku w Lipsku wokół starostwa i Lipskiego Centrum Kultury zostały przez Ciebie otagowane "maxspeed=20 km/h". Domyślną jednostką prędkości jest kilometr na godzinę (według maxspeed=*), więc nie ma potrzeby jej dodatkowego oznaczania.

3. Mam wątpliwości co do tagu "highway=pedestrian" wokół wcześniej wspomnianych dróg na Rynku. Tag ten jest przeznaczony dla deptaków. Ruch samochodowy jest tam więc znacznie ograniczony. Biorąc pod uwagę obecność tagów "motor_vehicle=yes" i "maxspeed=20 km/h", bardziej zasadnym tagiem jest "highway=living_street" (strefa zamieszkania). Polecam lekturę stron wiki (osm.wiki/Pl:Tag:highway%3Dpedestrian, osm.wiki/Pl:Tag:highway%3Dliving_street). Jeżeli masz odmienne zdanie, możesz je tutaj uzasadnić.

4. Tag "highway=service" dla alejki parkingowej przed starostwem (way/471224971) był prawidłowy, jako że jej wyłączną funkcją jest dojazd do parkingu i nie jest ona (zapewne) drogą publiczną (nie mylić z ogólnodostępną). Można było z tego powodu pokusić się o dodanie tagu "service=parking_aisle".

Ortofotomapa czasowa użyta w tym zestawie zmian składała się ze zdjęć aktualnych w dniu 1 listopada 2020 roku.

To be honest, I've never thought of the way of reporting this kind of errors, but if I did it, I would contact with country office (urząd gminy), which is responsible for naming streets, first and then with Central Statistical Office (Główny Urząd Statystyczny), which is responsible for maintaining the registry.

This was probably the first time I found the difference, since it was an extraordinary case to me.

Thanks for the photos! I was a bit suprised when I came across a named road in such a small village, but you resolved my doubts.

Is there any sign with this name? Is it just a local name? According to TERYT registry, there is no street/road called this way here.

Witaj!
Według opisu na OSM Wiki (osm.wiki/Pl:Key:crossing), tag crossing=uncontrolled odnosi się do sytuacji, w której przejście jest tylko oznaczone, a nie ma przy nim sygnalizacji. W związku z tym zmiana na crossing=controlled jest nieprawidłowa. Jeżeli jednak sygnalizacja jest obecna, należy użyć tagu crossing=traffic_signals. Niemniej jednak tag crossing:markings=zebra jest poprawny.

Kilka uwag to Twojej edycji:
1. Jeżeli chodziło Tobie o stację LPG, to taki punkt oznacza się amenity=fuel + fuel:lpg=yes (patrz: amenity=fuel).
2. Obecna nazwa jest zbędna, biorąc pod uwagę zasadę podaną na tej stronie (osm.wiki/Pl:Dobre_praktyki#Nie_używaj_tagu_name_do_opisywania_rzeczy).
3. Według ortofotomapy, z której korzystałeś, w tym miejscu nie ma budynku; albo został on niedawno postawiony, albo w tym miejscu jest co najwyżej daszek.
4. W nawiązaniu do poprzedniego komentarza: tag addr:city nie oznacza miejscowości-siedziby poczty, a miejscowość z nazwanymi ulicami. W tym przypadku jest on więc zbędny.
Niemniej jednak dziękuję za Twój wkład. Powodzenia!

Zastanawiam się, czy nie byłoby lepiej, gdyby krawężniki nie były usuwane, a co najwyżej ich tagowanie było poprawione na barrier=kerb.

Zmiana została wycofana (powód: fikcyjne dane) (patrz: changeset/152284938)

Zmiana została wycofana (powód: fikcyjne dane) (patrz: changeset/152284938)