Te drzewa były już zresztą raz przegtagowane, a Ty przywracasz na nich niepoprawnie zastosowane name

Część,
Gatunki drzew to nie są ich nazwy własne. Nie powinny być w name tylko w taxon osm.wiki/Pl:Key:taxon albo species (osm.wiki/Pl:Key:species).
Pozdrowienia

Cześć,
To nie wrzosowisko. Takie przyuliczne nasadzenia kwiatów (jeśli nie jest to po prostu trawnik) zwykle opisuje się kombinacją leisure=garden + garden:type=street_side

Natomiast jako wrzosowisko (natural=heath) rozumiemy obszar naturalny - patrz: osm.wiki/Pl:Tag:natural%3Dheath
Pozdrowenia

Dlaczego usunąłeś drogę way/802967638, po czym dodałeś ją jako nowy obiekt, zubożony o wszystkie szczegóły, które ją opisywały, zamiast usunąć po prost tagi access? Dodatkowo usunąłeś historię obiektu - w ten sposób nie mapujemy.
Rzuć okiem na: osm.wiki/Keep_the_history
Do wycofania.

No tak, z argumentem o ikonie rzeczywiście nie da się dyskutować :D

Mimo wszystko, jeśli masz w planach zacząć zmieniać to na masową skalę, to warto by to przedyskutować ze społecznością na forum, albo discordzie, jakie jest ogólnokrajowe (lub przynajmniej warszawskie) stanowisko na ten temat, żeby zachować spójność w tagowaniu. Może w rezultacie tej ewentualnej dyskusji wyniknie jakaś drobna korekta definicji na wiki, żeby usunąć niejednoznaczności.

Ale w definicji na osm_wiki (zarówno w wersji polskiej i angielskiej) nie ma słowa o tym, że nie musi - jest to przedstawione jako warunek konieczny, więc te krótkie definicji nie spełniają ;)
To jest oczywiście gra słów i jak to często bywa, w dokumentacji są nadużywane zwroty "zazwyczaj", a my na mapie "zazwyczaj" musimy się mierzyć z sytuacjami wybiegającymi poza ten przeciętny standard, albo będące na jego pograniczu :)

Uprzedziłeś mnie, bo właśnie chciałem się do tej długości odnieść. Definicja na wiki (traffic_calming=table), poza tą płaską częścią (faktycznie - trochę to dwuznacznie sformułowane) mówi właśnie o tym, że jest to właśnie dłuższa wersja hump (który wg tejże wiki ma zwykle 2-4 m) - na tyle, żeby zmieścił się tam cały samochód, przez co spowalnianie ruchu nie jest tak intensywne. I wg mnie to właśnie ten fragment jest kluczowy dla tej definicji i odróżnia table od hump.
Szczerze mówiąc, nie zauważyłem, by w Warszawie krótkie spowalniacze były w masowej skali mapowane jako table (choć oczywiście takie przypadki mogą się zdarzyć), pomimo tego że - jak zauważyłeś - są w większości spłaszczone.

Cześć,
Super, że tak szczegółowo mapujesz drobne obiekty, ale mam uwagę odnośnie ul. Fałata: progi spowalniające, które się tam znajdują (node/9051854411), to nie są "table", tylko "hump" (traffic_calming=hump) Table oznacza, że całe skrzyżowanie lub przejście dla pieszych jest podwyższone (traffic_calming=table)
I dlaczego w obu kierunkach (direction=both) skoro to jednokierunkowa ulica ? ;)
I jeszcze odnośnie znaków drogowych (np. tu: node/10160401976) - niby nie jest to niepoprawne, ale rozważ jednak ich umieszczanie jako węzłów na drogach, bo ze znaków mapowanych jako osobne obiekty chyba obecnie żadna nawigacja nie jest w stanie zrobić użytku.
Pozdrowienia

Hej,
Jest o tym wzmianka choćby w linku, który podrzuciłeś.
Chodzi o to, że mapowanie obszarów drogowych jako highway=* + area=yes jest typowym tagowaniem pod render i może generować problemy z routingiem - każdy obiekt otagowany jako highway=* jest brany pod uwagę przez nawigacje, dlatego dokładne obrysy obszarów drogowych powinny być tagowane wyłącznie jako area:highway, natomiast jako podstawową dla celów nawigacji rysuje się linię wzdłuż takiego obszaru, np. chodnika otagowaną jako highway=* (oczywiście już bez area) - takie linie zresztą są narysowane w wzdłuż dróg/ścieżek bedacych przedmiotem tej edycji. Więc narysowanie dwóch obiektów: linii highway oraz obszaru opisanego zestawem: area:highway + highway +area jest niepoprawne z jeszcze jednego względu - dubluje obiekt typu highway na danym obszarze, a więc narusza zasadę "jeden obiekt, jeden element w bazie" (osm.wiki/Pl:Jeden_obiekt,_jeden_element_OSM).
Jeśli spróbujesz wyznaczyć trasę po elemencie otagowanym jako highway=* + area=yes, to zobaczysz, że aplikacja będzie próbowała prowadzić po obrzeżach takiego elementu (wzdłuż linii obrysu).
Pewnym wyjątkiem są obszary highway=pedestrian, na których ruch pieszych może być wielokierunkowy highway=pedestrian#Squares_and_plazas - nieliczne nawigacje, potrafią poprowadzić np. po najkrótszej drodze zawierającej się w obszarze highway=pedestrian i to m.in. właśnie dla nich uzupełnia się o area=yes na takich obszarach, żeby pomóc odróżnić je od liniowych highway=pedestrian (stosowanych na promedach/deptakach/ulicach gdzie dopuszczony jest wyłącznie ruch pieszy)

Ogólnie zawsze rozdzielamy: highway=* tam, gdzie ma być prowadzony routing, a area:highway do szczegółowego przedstawienia obrysów dróg.
Niestety area:highway nie renderuje się na podstawowym stylu mapy, ale już np. na polskich kafelkach, tj. https://tiles.osmapa.pl/ jest wizualizowane area:highway=footway.
Pozdrowienia

Czemu na falochronie zrobiłeś landuse=residential?

Tu chodzi bardziej o place w rozumieniu obszarów, po których pieszy może się swobodnie poruszać w różnych kierunkach zamiast tylko "wzdłuż" jak na typowym chodniku. Każdy obiekt otagowany jako highway=* jest brany pod uwagę przez nawigacje (może z wyjątkiem highway=street_lamp ;) Większość aplikacji nie jest w stanie poprowadzić przez obszar takiego placu i będzie próbowała prowadzić po obrzeżach placu (wzdłuż linii obrysu), ale są też nieliczne nawigacje, które potrafią poprowadzić np. po najkrótszej drodze zawierającej się w obszarze highway=pedestrian i to m.in. właśnie dla nich uzupełnia się o area=yes na takich obszarach, żeby pomóc odróżnić je od liniowych highway=pedestrian (stosowanych na promedach/deptakach/ulicach gdzie dopuszczony jest wyłącznie ruch pieszy (np. way/504277590)

Ogólnie: highway=* tam, gdzie ma być prowadzony routing, a area:highway do szczegółowego przedstawienia obrysów dróg.

Niestety area:highway nie renderuje się na podstawowym stylu mapy, nad czym też ubolewam, ale już np. na polskich kafelkach, tj. https://tiles.osmapa.pl/ jest wizualizowane area:highway=footway.

Cześć,
Mapowanie obszarów drogowych: (np. way/1102913595) jako highway=* + area=yes jest niepoprawne - typowo pod render i może generować sporo problemów z routingiem. Zamiast tego takie obszary oznaczamy jako area:highway (area:highway=*).
Wyjątkiem są obszary highway=pedestrian, na których ruch pieszych może być wielokierunkowy highway=pedestrian#Squares_and_plazas
Dodatkowo - highway=pedestrian + area= yes nie jest przeznaczone dla typowych obszarów chodników (jak tu: way/1102913584) - te powinny być oznaczane jako area:highway=footway
Pozdrowienia

Cześć,
Uszczegóławiając linię brzegową zmieniłeś tu przebieg granic administracyjnych:
1) miejscowości Kadyny (relation/14410850) na odcinku way/1082972316
2) parku krajobrazowego (relation/4522399) na odcinku way/729153061
IMO ta część edycji jest wadliwa i powinna zostać wycofana, bo linie granic administracyjnych są bytami wirtualnymi, które ani nie powinny być łączone z przebiegiem innych "fizycznych" obiektów, ani też "dopasowywane" do aktualnego, dość zmiennego (często wręcz zmiennego wraz z poziomem wody) przebiegu linii brzegowej - formalna granica miejscowości nie zależy przecież od poziomu lustra wody ;) dlatego powinna pozostać nienaruszona w swoim dotychczasowym przebiegu.
Pozdrowienia

Niedawno została przegłosowana propozycja crossing:markings (crossing:markings=*), która wydaje się w bardziej uniwersalny sposób opisywać rodzaj wymalowania, więc jeśli już kogoś bardzo razi crossing_ref, to proponuję zamiast usuwać - przetagować wg tego nowego schematu

Wszystko się zgadza - landuse, czyli sposób zagospodarowania obszaru - to nie stoi w sprzeczności z natural=beach. Tu obszar plaży jest zagospodarowany jako przystań rybacka wraz z całą infrastrukturą techniczną świadczącą o takim sposobie użytkowania - jest czynny wyciąg linowy (którego ślad na mapie jest widoczny jako ta dalba zwrotna: node/9077294033, są budynki techniczne stacji napędowych wciągarki, są inne budynki techniczne/magazynowe do przechowywania ryb, itp. (way/716827461). W każdym razie nie jest fragment zwykłej, nieuzbrojonej plaży. Chociaż rzeczywiście na bieżącej orto nie widać kutrów.
Dodatkowo, Industrial=port, a więc i konsekwentnie landuse=industrial są tagami nadrzędnymi wobec port=fishing, więc ich brak przy obecności tego ostatniego wskazuje na niepełne tagowanie.

Hej,
Nie zgodzę się z tym. Granice tego obszaru są opisane tabliczkami ostrzegawczymi, że jesteś na terenie przystani, zachowaj szczególną ostrożność, przebywanie na terenie wiąże się z niebezpieczeństwami, uwaga na liny pracujących wciągarek, itd. To jest typowa przestrzeń portowa, której granice są ściśle określone (patrz source), i jako taka była imho poprawnie oznaczona. A na pewno nie jest to leisure=marina, która z definicji oznacza port jachtowy używany rekreacyjnie.

Thanks!

Hi,
Thanks for the revision - you're definitely right that these slipways are not seamarks anymore. Nontheless, I think at least disused:leisure=slipway tag should stay there.
Although one of them is built over by the wharf and the second one is a temporary storage place for some concrete plates ;) these facilities are still clearly visible on the ground, so I'd rather leave them tagged as disused slipways.
Also just in case anyone would like to recreate them basing on the outdated imagery.

As written here: changeset/126326274
the former state was correct and removed landuses were up to date, so this changeset should be reverted