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

Hi,
Why did you add the construction site? The waterway is officially opened since yesterday, hence the construction landuse have been removed in
changeset/126300860
It seems that you traced from the old aerial imagery so these changes don't reflect the current state of the landuse.

Cierpliwości - punkt jest usunięty, ale zwykle musi minąć kilka dni zanim dane zostaną zaktualizowane w różnych aplikacjach korzystających z OSM.
Dodatkowo pytanie - czy ta apteka jest może gdzieś w okolicy? Może zamiast usuwać, warto było ją przenieść we właściwe miejsce?

Informację o nawierzchni przekazuje się tagiem surface (osm.wiki/Pl:Key:surface), a nie opisem w nazwie. Unikaj opisywania obiektów za pomocą nazwy. Rzuć okiem na: osm.wiki/Pl:Nazwy#Nazwa_jest_tylko_nazw%C4%85

Ścieżki: way/979755118, way/979754938 oraz way/183463639 były już odpowiednio otagowane (surface=dirt i surface=sand)
dlatego przywróciłem do poprzedniego stanu:
changeset/126106111

Pozdrowienia

Cześć,
Full_name chyba nie jest nawet udokumentowane na wiki, więc może być słabo ze wsparciem. Zdecydowanie lepsze wydaje się w tym przypadku wrzucanie pełnych nazw MOPów do alt_name lub official_name
Rzuć okiem na name=*
Pozdrowienia

Tak na dobrą sprawę te "widełki" w ogóle powinny zostać uproszczone do jednej linii. Na tak krótkich odcinkach typu wysepki na przejściach zwyczajowo nie dzieli się drogi na dwie jezdnie: https://forum.openstreetmap.org/viewtopic.php?pid=850847#p850847