piebro/osm-data huggingface dataset:
eggie (2025-02-24 21:50:37+00:00): Hoi...

Het is een grijs gebied.
Een Eigen Weg is bv geen Verboden Toegang. Ook niet met bord. Dus access=permissive
Je mag een weg niet zomaar ontrekken aan de openbaarheid.
De eigenaar mag je wel de toegang ontzeggen als hij dat nodig vindt.
Denk aan de bossen in Coronatijd en buitendijkse 'fietspaden' van Rijkswaterstaat.
Je mag dus op veel meer plaatsen komen dan iedereen denkt.
Akkers.. schouwpaden..klompenpaden. enz. Bij overlast kan de boer je wel te toegang ontzeggen middels aanroepen.
In het UK kennen we de countrycode.
Je mag daar echt overal wandelen zolang je je gedraagd. Permisdive dus.
..en access=yes taggen we nooit..dat is default.

Bij art 461 wvs ligt het anders.. access=private.. maar ook daar is het niet zwartwit.
Toegangswegen routeren niet met private..  PostNl en DHL..e.d. willen toch bezorgen.. lees routeren.
Daarom daar vaak toch permissive ipv private.
Je mag dat bordje passeren als je er wat te zoeken hebt.
Een gesloten hek is private.
ChehrehBargi (2025-07-08 22:44:01+00:00): Hello
Your action in correcting the name of this park is almost correct. After all, you should have created the name in the whole relationship and deleted the previous name. The full name of this park is Shohadaye karkhanasan park.

سلام
اقدام شما در اصلاح نام این پارک تقریبا صحیح است. منتهی باید در کل رابطه نام را ایجاد میکردید و نام قبلی را حذف می نمودید نه در قسمتی از آن. نام کامل این پارک، بوستان شهدای کارشناسان است.
sgalaxya71silver (2025-08-22 09:05:36+00:00): Thank you for your precise note.
سپاس از تذکر دقیق شما.
🙏
ChehrehBargi (2025-08-22 12:12:55+00:00): Wishing you good health.
domiden (2025-02-18 21:31:16+00:00): Should be: “… ("Kassel-Vorderer Westen").”
BCNorwich (2025-02-19 08:17:43+00:00): Hi, Welcome to OpenStreetMap.

I think that building is two semi detached houses. I've amended the building outline. But which one is Seaview? I've tagged the names as I think they should be with Seaview to the east, could you please confirm this? Secondly is Seaview a holiday let cottage?

Regards Bernard.
eggie (2025-02-19 07:15:25+00:00): Dag Rutger.. Er zat een spelfout in de straatnaam en het adres was onvolledig. Ik heb het aangepast.
MVG
eggie
DerSchmopf (2025-02-21 10:00:52+00:00): Es gibt ihn wieder? https://www.ahrtal.de/pois/ahrtal-express/poi.html
bernward1 (2025-02-22 09:44:28+00:00): Die alte Route ist offensichtlich nicht mehr ganz dieselbe. Aus der Ferne kann ich sehen, dass die neue Brücke in Ahrweiler noch nicht richtig berücksichtigt ist.
gscscnd (2025-02-19 07:31:22+00:00): Zerknij jeszcze tutaj, może coś przydatnego znajdziesz:
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dshooting_ground
https://wiki.openstreetmap.org/wiki/Tag:sport=shooting
mga_geo (2025-02-20 06:04:06+00:00): Bonjour,
Attention ! la création de ronds-points peut casser de très nombreuses relations route=bus, dans ce cas.
Même avec JOSM c'est une opération délicate.
Pouvez-vous corriger ?
Marc
Britzz (2025-02-22 10:21:46+00:00): Merci pour cette alerte, je les ai rétablies
Marek-M (2025-02-19 06:27:51+00:00): Cześć, dane zebrane w terenie nie były tutaj problemem tylko rozdzielenie DDPiR na dwie linie przy braku rozdziału fizycznego. Wg informacji w mediach taka właśnie tutaj została wybudowana https://wroclife.pl/artykul/6063/deweloper-przebudowal-ulice-na-wroclawskich-maslicach

DDPiR bez rozdziału fizycznego mapujemy 1 linią `path`
https://wiki.openstreetmap.org/wiki/Pl:Rowery#Drogi_dla_pieszych_i_rowerów
pavvv (2025-02-19 06:40:43+00:00): Czyli tylko wybiórczo trzymasz się wiki.
Może przekona Cię dyskusja na wiki, gdzie wypowiedziało się ponad 100 osób https://community.openstreetmap.org/t/zniszczenie-mojej-pracy-nad-infrastruktura-rowerowa/125418
Marek-M (2025-02-19 07:22:06+00:00): Poprawię dane podane przez @pavv - wypowiadało się tam 20 osób ale postów jest ponad 100 ale tak, to jest dobry wątek z wieloma punktami widzenia :)
Yog Sot (2025-02-19 09:21:17+00:00): na tym zdjęciu widzę, że rowerówka jest odseparowana od chodnika krawężnikiem i inną nawierzchnią, więc mikromapowanie takiego rozdzielenia jest zasadne, chociaż dla tego konkretnego miejsca nie jest tak krytycznie istotne. Jedna najważniejsza informacja, to na schemacie od razu widać gdzie pieszy porusza się wraz z rowerami, a gdzie osobno. Bez rozdzielenia człowiek nie wie tez po której stronie jest infra i że np musi przekroczyć tą slępą odnogę rowerówki do stojaków rowerowych. 

Człowiek nie routing, nie czyta tagów, tylko schemat ;)
maro21 (2025-02-24 22:02:00+00:00): Jedną linię można mapować i nikt tego nie zabrania. Można też mapować dokładniej, przez dwie linie, gdzie do każdej linii można podać szczegóły, np. nawierzchnię, gładkość, szerokość i inne parametry. Mapujemy od ogółu do szczegółu, a nie odwrotnie. Mamy zasadę one feature - one OSM element. Po narysowaniu jednej linii, na mapie widać jedną linię, więc nie widać i chodnika i drogi rowerowej. Większość społeczności OSM preferuje osobne linie. A jedna linia jest w przypadku znaku C-13/16 z poziomą linią. Poza tym ciągów pieszo-rowerowych nie ma już w Polsce od lat - przepisy się zmieniły dawno temu - są drogi rowerowe i chodniki. Chętnie bym zrozumiał w czym i dlaczego przeszkadza dokładne mapowanie, bo jak na razie nie widziałem żadnych argumentów.

Faktem jest, że black_flag_baby był na miejscu, zmapował, dodał nawierzchnię i gładkość, a pavvv te dane usunął. Dane zebrane w terenie mają priorytet niż armchair mapping.
Marek-M (2025-02-24 22:10:55+00:00): Potyczki w temacie 1 czy 2 linie są już rozgrzebane tutaj: https://community.openstreetmap.org/t/zniszczenie-mojej-pracy-nad-infrastruktura-rowerowa/125418

Szkoda marnować dodatkowy czas w dyskusji do changesetu.
pavvv (2025-02-24 22:17:44+00:00): Tak bardzo trzymasz się tego wiki, ale nie kiedy przychodzi do mapowania niezgodnie z Twoimi zasadami. https://wiki.openstreetmap.org/wiki/Pl:Rowery#Drogi_dla_pieszych_i_rower%C3%B3w
To nic, że na mapie nie widać dwóch linii. Nie mapujemy pod render. Routing wie, że są tam rozdzielone droga dla rowerów i chodnik. W celu dokładnego opisu pozycji DDR i chodnika istnieje tag area:highway.
Z dyskusji wynika, że większość społeczności preferuje jedną linię, szczególnie wschód tych aktywnych.
Można powiedzieć, że drogi oznaczone znakami C-13/16 oraz C-16/13 mapujemy tak samo, tylko ze zmianą tagu segregated=*.
W mapowaniu dwoma liniami przeszkadza to, że jest to niekonsekwentne z resztą dróg, jak drogi samochodowe. Nie mapujemy przecież każdego pasa jako oddzielną linię.

Jeśli usunąłem nawierzchnię i gładkość drogi, to przepraszam, zapomniałem o tagach cycleway:surface=* i cycleway:smoothness, ale nie wydaje mi się, że jest to powodem do revertowania zmiany, że później nie da się jej przywrócić z powodu konfliktów.
black_flag_baby (2025-02-28 22:15:22+00:00): Jeśli byłoby się w terenie, albo z uwagą przeanalizowało zdjęcie wrzucone do uwagi od której się to zaczęło, to można zauważyć, że nie ma w terenie znaku C-13/16/C-16/13, tylko znaki C-13. Technicznie więc biorąc nie mamy tam do czynienia nigdzie z drogą dla pieszych, a zwykłym chodnikiem. Widać tam nawet znak C-13a, który został zignorowany w pierwotnej zmianie, w której droga rowerowa błędnie pociągnięta była na ślepo na południe ulicy Stodolnej.

Komentarz dotyczący, że w dyskusji większość osób się udziela za łączeniem jest stronniczy, sam pavvv jesteś przecież uczestnikiem tej dyskusji. Ja dla odmiany uważam, że nie mniej słyszalnym jest głos o rozdzieleniu dróg. Widać to nawet w zaangażowaniu innych użytkowników w komentarzach do tej zmiany. Zwolennicy jednej kreski są w tej dyskusji dość mało otwarci na zrozumienie drugiej strony, mimo że team "dwie kreski" przedstawiał wiele sensownych argumentów za stosowaniem ich i są raczej zgodni co do np mapowania CPRu rozdzielonego farbą. Jakoś nikt nie usuwa zmapowanych osobną kreską chodników, które od jezdni są rozdzielone jedynie chodnikiem.

W ogóle fakt, że zapoznałeś się z dyskusją, która na celu miała podniesienie problemu niszczenia czyjejś pracy, która jak najbardziej była prawidłowa, co przedstawia artykuł z wiki, który sam wklejasz (Ref S5, którego mam wrażenie starasz się aktywnie nie zauważać), gdzie jednym z wniosków było, że obie koncepcje mogą jak najbardziej współistnieć, a następnie sam powtarzasz taką akcję, jest dla mnie demotywujący do dalszej pracy. Ciężko również nie odebrać tego jako ataku, prywatnej vendetty przeciwko złym dwóm liniom, której ta moja drobna zmiana nieszczęśliwie się napatoczyła.

Mapowanie zacząłem z uwagi na chęć dokładniejszego zmapowania infrastruktury rowerowej, w ostatnim czasie skupiając się na wręcz masowym poprawianiu informacji o nawierzchni, która jest renderowana w wielu widokach, nawet w podstawowym. Takie moje oczko w głowie. 

Na koniec dodam tylko, że ostatnia ponowna zmiana po revercie maro21 psuje tą pracę, bo ponownie zrobiona została niepoprawnie, mimo że na wiki jest wyjaśnione jak to dobrze wykonać na jednej linii.
pavvv (2025-03-01 08:38:14+00:00): Po coś jednak istnieje tag segregated=yes, hm? Dla routingu łatwiej jest mieć jedną kreskę. Rysowanie przejścia dla pieszych i rowerów jedną kreską, a co za tym idzie dodawanie jednego węzła highway=crossing jest zgodne z zasadą jeden obiekt, jeden element OSM.
Nie wiem o jakim usuwaniu danych mówisz, ani psuciu pracy. Poczytaj sobie za to https://wiki.openstreetmap.org/wiki/Pl:Celowo_b%C5%82%C4%99dne_tagowanie_pod_renderer
black_flag_baby (2025-03-02 20:04:29+00:00): Świetny przypadek dla segregated=yes masz tu:
https://www.bing.com/maps?cp=51.111045%7E17.048842&lvl=18.3&pi=-10.7&style=x&mo=om.1&dir=206.7
Albo tu:
https://www.bing.com/maps?cp=51.112382%7E17.01829&lvl=18.3&pi=-5.4&style=x&mo=om.1&dir=230.9
Co z resztą opisałem w swoim poprzednim komentarzu. W obu przypadkach ciągi piesze i rowerowe znajdują się na jednej i tej samej konstrukcji o tym samym typie nawierzchni, posiadają wspólną geometrię.

Zarzucasz mi mapowanie pod render, co jest nieprawdą, a nawet sam nie próbujesz zrozumieć swoich błędów, przez które pogorszyłeś jakość obecnej mapy. Usunąłeś informację o nawierzchni dodając jedynie tagi cycleway/footway:surface, które wg podlinkowanej dokumentacji nie są wystarczające. To opisałem jako widoczne na renderach (rowerowym i podstawowym). Nie mówię już nawet o braku oznaczenia strony, po której jest ciąg pieszy i rowerowy, bo dokumentacja tego nie wymaga. A w omaiwanym miejscu nawet nie ma wyznaczonego ciągu pieszego w rozumieniu PoRD - żadnego wariantu znaku C-16 na omawianym odcinku nie ma.

Jak już wspomniałem, moim oczkiem w głowie jest nawierzchnia dróg rowerowych we Wrocławiu (bardziej surface niż smoothness). Swoimi zmianami zatarłeś tą informację. Jeżeli dalej nie rozumiesz błędu, przeczytaj DOKŁADNIE Ref S5 z dokumentacji rowerowej wcześniej tu podlinkowanej. 

Zmianę wprowadziłeś tylko dlatego, że uważasz, że jedna z dopuszczonych metod mapowania (przytaczam ponownie Ref S5 z dokumentacji o rowerach) Ci się nie podoba. De facto jest to wandalizm.
pavvv (2025-03-02 20:31:29+00:00): >W obu przypadkach ciągi piesze i rowerowe znajdują się na jednej i tej samej konstrukcji o tym samym typie nawierzchni, posiadają wspólną geometrię.
Różne nawierzchnie to nie jest fizyczne rozdzielenie. Nie mapujemy oddzielnie np. kiedy jeden pas jezdni jest betonowy, a drugi asfaltowy. Do mapowania dokładnej geometrii masz area:highway.

> Zarzucasz mi mapowanie pod render, co jest nieprawdą
Można to tak zrozumieć czytając "Mapowanie zacząłem z uwagi na chęć dokładniejszego zmapowania infrastruktury rowerowej, w ostatnim czasie skupiając się na wręcz masowym poprawianiu informacji o nawierzchni, która jest renderowana w wielu widokach, nawet w podstawowym."

> Usunąłeś informację o nawierzchni dodając jedynie tagi cycleway/footway:surface, które wg podlinkowanej dokumentacji nie są wystarczające.
Jedynie? To całkowita informacja o drogach, jaka jest potrzebna w tym miejscu. W mojej opinii nie ma potrzeby dodawania surface=paved pod mniej zaawansowane aplikacje, ale jeśli uważasz to za stosowne, to możesz te tagi dodać.

> Nie mówię już nawet o braku oznaczenia strony, po której jest ciąg pieszy i rowerowy, bo dokumentacja tego nie wymaga.
Tak, to jest jedyna informacja, którą się traci przy mapowaniu jedną linią. Jeśli masz pomysł na to, jak ją zaimplementować, to możesz zrobić propozycję i spróbować ją przegłosować. Mnie się podoba to, że CyclOSM już renderuje w wyznaczonych stronach DDR i chodnik, więc możliwe, że niedługo zacznę do tego dostosowywać DDPiRy.

> Jak już wspomniałem, moim oczkiem w głowie jest nawierzchnia dróg rowerowych we Wrocławiu (bardziej surface niż smoothness). Swoimi zmianami zatarłeś tą informację. Jeżeli dalej nie rozumiesz błędu, przeczytaj DOKŁADNIE Ref S5 z dokumentacji rowerowej wcześniej tu podlinkowanej.
Niczego nie zatarłem. Zaawansowana aplikacja odczyta właściwe wartości. surface=paved i tak nie daje prawie żadnej informacji o nawierzchni, na której tak bardzo Ci zależy. Jeśli bardzo brakuje Ci tej informacji, to możesz dodać ten tag, nawet na większą skalę. Ty jednak przeczytaj "Należy zwrócić uwagę na fakt, że ten sposób tagowania w angielskiej wiki wywołuje kontrowersję, ponieważ nie istnieje fizyczne rozdzielenie między ścieżką rowerową a ciągiem pieszym. Zalecają tam w miarę możliwości inny sposób tagowania."

> Zmianę wprowadziłeś tylko dlatego, że uważasz, że jedna z dopuszczonych metod mapowania (przytaczam ponownie Ref S5 z dokumentacji o rowerach) Ci się nie podoba.
Tak naprawdę sposób mapowania takich miejsc już został ustalony, tylko tacy jak Ty nie chcą się dostosować. Powiedz co jest lepsze: schemat dobry i powszechnie uznawany, czy schemat dobry, ale kontowersyjny? Czy tak złe jest poprawianie z tego drugiego na pierwszy?

> De facto jest to wandalizm.
Nie jest, ponieważ niczego tu nie niszczę, tylko zmieniam schemat na szerzej uznawany oraz preferowany.
black_flag_baby (2025-03-02 21:31:31+00:00): > Różne nawierzchnie to nie jest fizyczne rozdzielenie. Nie mapujemy oddzielnie np. kiedy jeden pas jezdni jest betonowy, a drugi asfaltowy. Do mapowania dokładnej geometrii masz area:highway.

Różne nawierzchnie nie są rozdziałem, z tym się zgadzam, ale tu nie ogranicza się to tylko do tego. Nie ma tu też mowy o dwóch pasach, a dwóch osobnych ciągach. Rozdział jest krawężnikiem i różnicą poziomów dróg, są to dwie różne konstrukcje. Tak samo jak jezdnia i przyległy chodnik - ich też nie mapuje się z tagiem segregated. Więc w jednym wypadku można, a w innym nie?

> W mojej opinii nie ma potrzeby dodawania surface=paved pod mniej zaawansowane aplikacje, ale jeśli uważasz to za stosowne, to możesz te tagi dodać.

Przecież dodałem, a Ty to usunąłeś. Według Twojej opinii możesz sobie ignorować dokumentację kiedy Ci się podoba i przyczepiać się do POPRAWNEJ. To, że jest nieuznawana, to wciąż tylko opinia (która jest stronnicza, nie poparta żadnymi mierzalnymi wartościami), a nie fakt, dokumentacja to DOPUSZCZA. A kontrowersje nie oznaczają zakazu stosowania. A jeżeli inna opcja nie przekazuje innych istotnych informacji, to jest ona gorsza. Poza tym mapy nie tworzy się tylko pod zaawansowane aplikacje.

>Tak, to jest jedyna informacja, którą się traci przy mapowaniu jedną linią. Jeśli masz pomysł na to, jak ją zaimplementować, to możesz zrobić propozycję i spróbować ją przegłosować. 

Tak, mam pomysł jak to zaimplementować. Opisuje to Ref S5, punkt drugi w dokumentacji rowerowej. 

>Mnie się podoba to, że CyclOSM już renderuje w wyznaczonych stronach DDR i chodnik, więc możliwe, że niedługo zacznę do tego dostosowywać DDPiRy.

Poczytaj sobie za to https://wiki.openstreetmap.org/wiki/Pl:Celowo_b%C5%82%C4%99dne_tagowanie_pod_renderer

>Nie jest, ponieważ niczego tu nie niszczę, tylko zmieniam schemat na szerzej uznawany oraz preferowany.

Dokumentację stosujesz wybiórczo i ignorujesz te elementy, które Ci się nie podobają. Sam deklarujesz, że będziesz tworzyć mapy pod jeden konkretny silnik graficzny, a to mi zarzucasz mapowanie pod render. Powołujesz się na wymyślone "nieuznawanie" co jest jedynie Twoim wymysłem, bo dyskusje pokazują zupełnie co innego, w przytoczonym wcześniej wątku na wiki Yog Sto przytacza ankietkę zrobioną na zewnątrz. Może nie do końca ze sztuką i na małej próbie, ale miażdżąca przewaga jest po przeciwnej stronie. Odnosząc się do bardzo licznych wypowiedzi innych użytkowników na forum OSM ciężko mi zrozumieć skąd wziąłeś "powszechnie uznawany".
eggie (2025-02-19 08:14:22+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
b-jazz (2025-02-19 20:47:27+00:00): Hey there Jpipe323,

Thanks for your contributions to golf courses on OSM. We appreciate the efforts.

I was wondering if I could ask a small favor in case you continue to map golf courses. When you draw a fairway like https://www.openstreetmap.org/way/1361016157, could you select both the fairway and the green and combine them into a single object (called a multipolygon) by pressing "C" on the keyboard or right clicking and selecting "Merge". That would save me the effort of coming back at a later date and making that change myself. Thanks!
Jpipe323 (2025-02-22 20:32:33+00:00): Hey sorry for the late response. That is no problem I will keep that in mind for next time I do a map. I am very new to this mapping. Any other pointers on mapping golf courses?
Jpipe323 (2025-02-22 20:43:28+00:00): Hey, I just tried to go in and group the greens and fairways but i was getting an error that the "features can't be merged". Any idea why that isnt working?
b-jazz (2025-02-22 21:08:48+00:00): No worries. Thanks for responding! I’m always here to answer golf course mapping questions. The best place to start is the following wiki: https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgolf_course

Can you leave a comment here about which fairway you are getting that error on? You should be able to get a link to that specific option on the bottom of the left sidebar. Or could be that the fairway and green intersect each other. That is the most common problem and needs to be addressed first before grouping them.
b-jazz (2025-02-22 21:11:12+00:00): On rereading your sentence, if you are selecting multiple greens and multiple fairways and grouping them once, that won’t work. You need to select one enclosing fairway, and anything that is fully contained within that fairway and group just those together.
Jpipe323 (2025-02-22 21:30:04+00:00): I think I got it all figured out now. I was just looking at it wrong... haha. Thanks for the help
eggie (2025-02-19 07:11:55+00:00): Dag Mr Glonass Heeft het pand ook geen adres meer?

MVG
eggie
treestryder (2026-05-30 16:05:20+00:00): I hope to check on whether this is actually named "Food Scrap Drop Off", while over that way for Bike and Seek today. It's descriptive tags already describe it well, with the description tag meant to fill in any gaps.
See "Don't use name tag to describe things" on https://wiki.openstreetmap.org/wiki/Good_practice#Don't_use_name_tag_to_describe_things
Descriptive names tend to clutter most renders. This really stood out in OsmAnd.
Aenet (2026-05-30 17:36:04+00:00): I named it that because I saw signs that point to it saying “food scrap drop off”. I’d be okay with the “name” tag being removed, I really don’t think what is essentially a compost bin needs a name
treestryder (2026-05-31 04:11:54+00:00): As you say, there is a sign that says "Food Scrap Drop Off".
https://mapillary.com/map/im/828823480021705

Sorry. Describing things in the name tag is a bit of a pet peeve for me.
geekbga2024 (2025-02-19 19:32:33+00:00): why do u remove the previous avenues names?
AngocA (2025-02-22 21:19:18+00:00): @Spaghetti Monster🍝 Thank you for this revert.

@geekbga2024 Street names in Bogota are the number. The other names could be in official name or alt name. This have been defined in the Colombian guide of mapping: https://wiki.openstreetmap.org/wiki/Colombia/Guide_for_mapping#Street_names
user_5359 (2025-02-19 13:01:39+00:00): Hello! Please have a look on https://www.osm.org/relation/18724275. Why can this relation be assigned to two German (!) administrative units? The source mentioned does not seem to know both values.
JeroenvanderGun (2025-02-19 14:34:44+00:00): According to the document, code 10042999 is the proper code for statistical purposes.

Code 10942115 (which was previously also included in OSM tagging) is mentioned in the table further below on the same page of that document, apparently stems from some other subdivision (which further splits the Rheinland-Pfalz part but not the Saarland part).
b-jazz (2025-02-19 19:55:45+00:00): Hi there AsYouAre,

Just wanted to let you know that a change you made to https://www.openstreetmap.org/way/918883786 was incorrect. You tagged the outer ring that defines the fairway as "golf=fairway", but it was already part of a multipolygon that correctly defined that. To add that tag when it already existed is saying that everything inside that polygon is fairway, including the green, which isn't correct. I'll fix it. I just wanted to let you know so you could avoid that in the future.
eggie (2025-02-19 07:16:47+00:00): Dag Jadey.. Svp geen adressen toekennen aan gebouwomtrekken.

MVG
eggie
Jadey- (2025-02-19 07:53:24+00:00): oki
trigpoint (2025-11-22 20:42:56+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/175004482
trigpoint (2025-11-22 20:43:01+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/175004482
eggie (2025-02-19 07:04:27+00:00): Dag Jadey    Je info heb ik samengevoegd met de bestaande adresnode
MVG
eggie
Lubana_808 (2025-02-19 00:07:08+00:00): I will appreciate if someone lets me know if I've done it wrong
NorthCrab_upload (2025-02-19 00:22:15+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy. Adres można oznaczyć na dwa sposoby: na obszarze (dokładniejsze) albo na punkcie. Aktualizując adres, należy się upewnić, czy w okolicy nie pozostały żadne duplikaty.
https://www.openstreetmap.org/node/8336189602
https://www.openstreetmap.org/way/896810724

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
NorthCrab_upload (2025-02-19 00:22:16+00:00): Zauważyłem, że Twoja zmiana zawiera nadmiarowe informacje. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Paczkomat nie powinien mieć nazwy. Nazwa nadawana jest automatycznie, na podstawie wartości brand. Opcjonalnie, numer identyfikacyjny może być przekazany w polu ref.
https://www.openstreetmap.org/node/9284892126

Dokumentacja paczkomatów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Tag:amenity%3Dparcel_locker

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
Fizzie-DWG (2025-04-17 00:58:04+00:00): DWG revert – undiscussed Organised import from unknown source

https://www.openstreetmap.org/changeset/165050348
conradoos (2025-02-27 19:30:55+00:00): I reverted the changeset, because you duplicated buildings.
Hufkratzer (2025-02-19 21:27:42+00:00): Hi,
https://www.openstreetmap.org/way/1361038666 und auch https://www.openstreetmap.org/way/1361038689 sehen mir eher wie Reitplätze aus als wie Reitanlagen im Sinne von https://wiki.openstreetmap.org/wiki/DE:Tag:leisure=horse_riding. In OSM werden Reitplätze normalerweise so getaggt wie der hier: https://www.openstreetmap.org/way/509326601
Hufkratzer (2025-02-19 21:31:38+00:00): Ein Beipiel aus deiner Gegend für eine Reitanlage mit Reitplätzen: https://www.openstreetmap.org/way/112604327#map=17/54.016652/10.580054&layers=P
RSun (2025-02-19 23:19:16+00:00): Danke für den Hinweis, habe beide Plätze korrigiert. Ist nicht immer einfach, die richtigen Tags zu finden ... ;-) Das OSM-Wiki ist nicht immer so hilfreich, wie es sein sollte. Oft schaue ich mir bei ähnlichen Objekten an, wie Andere es getaggt haben, aber das ist auch nicht immer korrekt. ;-)
Hufkratzer (2025-02-20 19:19:47+00:00): Ja, sicher, ist nicht immer einfach, meistens eher das Gegenteil.
Kannst ja das Wiki auch selbst verbessern. Ist halt alles von Freiwilligen gemacht.