Ochrona przyrody

nie wiem po co brniesz w dyskusję na temat który w żaden sposób nie zmienia wartości danych ani nie masz żadnego argumentu by akurat koniecznie użyć go w kolejności innej niż zaproponowałem

Szkoda, że tak dużo wiesz na temat OSM a nie wiesz że każdy z importów winien mieć skan fizycznego dokumentu aprobującego przekazanie danych do OSM. Dane te nie widnieją na stronie GDOŚ co może uprawdopodobniać tezę że zostały pozyskane od nich mimo wszystko bez oficjalnej zgody. Na wiki wyraźnie pisze, że zgoda użytkownika forum podającego się za pracownika (wcale nie musi tak być) danej organizacji nie jest tu wystarczająca. Martwi mnie że nie ma przy tym jednego chętnego z Zarządu który by wyraził chęć przekopiowaniem pisma o gotowej treści (którą nawet mógłbym jak powiedziałem wcześniej przygotować) na papier stowarzyszenia i przybić na niego pieczątkę i wysłać pod wskazany adres.

A świstak siedzi i zawija w te sreberka. Dużo powiedziałeś na podstawie informacji które podałem co ewidentnie znaczy że potrzebne to nie jest. Nie widzę powodu by to kogokolwiek do dyskusji przekonało, ale jutro wystawię plik *.osm z dwoma punktami.

9175 - Łódzkie
5176 - Lubelskie

To co należy - ręczna weryfikacja. Nie będzie to trudne gdyż obecnie w bazie dla Lubeskiego jest jedynie 96 obiektów oznaczonych jako denotation=natural_monument gdzie w Łódzkim jest ich 12…

taką kombinację akurat łatwo wyłapać dając w kreatorze "denotation=natural_monument OR name=“Pomnik przyrody”, ale jeśli dane w OSM są w danym przypadku źle opisane i dla takiego punktu nie ma nawet natural=* to jak dla mnie można przyjąć, że mogą być błędne i nie należy się nimi przejmować. Nie możliwe jest by przy imporcie wiedzieć bez pobrania obszaru w okolicy każdego z tych punktów czy ktoś sobie czasem nie wymyślił np. name=fajne drzewo. Nie planuję jednak tego robić

By uprzedzić pytanie to dla obiektów oznaczonych denotation=natural_monument które są w bazie a nie ma ich w gdoś to jeśli nadal widzoczne są na orto dać protected=no, jeśli obiektu nie widać to wywalić z bazy w osobnym changesecie

Jak widać na ORTO lub ISOK to jeśli jest potrzeba przesunąć obecny w OSM punkt do nowej lokalizacji. Jeśli nie widać to pozostawić w obecnej w bazie z tagiem fixme=sprawdzić lokalizację by łatwiej odszukać punkty różniące się pomiędzy bazami.

Można też w fixme podać położenie z GDOŚ, np. linkiem do tego serwisu.

Tu bym trochę uważał z circumference=* .
Skoro wiki określa, że chodzi o obwód na wysokości 1m, a w danych mamy obwód na wysokości 1,3m to jakoś wypadałoby to oznaczyć. Albo używając innego tagu (ktoś proponował circumference_13 czy jakoś tak, można też dać circumference:pl i opisać go co najmniej w polskiej i angielskiej wiki z linkami z opisu circumference… zresztą, circumference_13 należałoby tak samo opisać); albo używać circumference i z automatu dawać note=“Circumference is measured at 1,3m in Poland”. Pierwsze rozwiązanie wydaje mi się o tyle lepsze, że opisy powinny być w wiki, a nie w note=* przy każdym obiekcie w OSM.

Właściwie to możnaby też postawić potem bota, który by wyłapywał changesety, w których ktoś użyje w Polsce circumference=* i z automatu opatrywał changeset komentarzem zwracającym autorowi uwagę na różnicę między circumference i circumference:pl / circumference_13, czy jak to tam nazwiemy.

circumference:pl - Dobry pomysł, tyle czy potrzebny?
Rozmawiałem swego czasu z profesor od dendrologii i powiedziała mi, że 130 cm to właściwy standard, nie 100 cm. Nie wiem skąd społeczność międzynarodowa to 100 cm wzięła. Mniejsza z tym.

Edit: wcale nie mniejsza: Międzynarodowe wiki należy poprawić.
Wrzyććie sobie na tłumacza: https://de.wikipedia.org/wiki/Stammdurchmesser

Także po angielsku:
https://en.wikipedia.org/wiki/Diameter_at_breast_height

@rmikke & @marek kleciak
Nie ma potrzeby. W wątku w sprawie importów dla dla drzew w mieście Ottawa który przytoczyłem padły wypowiedzi, które przytoczyły artykuły z wiki wskazujące w nich jednoznacznie za 1,3m jako podstawową wartość dla pomiaru obwodu. Pozwolę sobie zamieścić bezpośrednie linki

https://lists.openstreetmap.org/pipermail/imports/2017-June/005050.html

Być może nadal tu i ówdzie na OSM Wiki widnieje, że pomiar należy wykonać na wysokości 1m, ale ogólny konsensus jest, że pomiar z 1,3m jest tym właściwym.

Mhm, w polskich tłumaczeniach artykułów było 1m. Poprawiłem.

No to w sumie problem można uznać za niebyły.

Sam bym nie wiedział że coś się w tej materii zmieniło gdyby nie dyskusja o drzewach na liście importów która dosłownie tyle co się rozpoczęła.

Oto i on http://bigvo.hopto.org/osm-extra/tree_sample.osm. Odnosząc się do całości danych to częstym jest by pewnych danych dla jednego czy drugiego województwa brakowało. Dla przykładu brak jest informacji o tym czy drzewo jest liściaste czy iglaste dla całego woj. lubelskiego. Nie jest to problemem gdyż jak widać w przykładzie na podstawie species uzupełniłem tą informację.

Czekając na odpowiedź kolegi tomalosa co do najlepszej drogi postępowania by oficjalną zgodę na użycie danych uzyskać z GDOŚ w dużej mierze ukończyłem przygotowywanie danych do importu dla woj. lubelskiego.

W tych kilku niewielkich zmianach znajduje się ich próbka. Jak by ktoś miał jakieś uwagi to proszę. Zastanawia mnie przede wszystkim kompletność oznaczenia relacji dla alei drzew. Wydaje się, że taka relacja winna spowodować wyświetlenie nazwy obiektu przez całą długość alei na mapie, a tak nie jest. Nie wiem czy to błąd oznaczenia czy też jednak to, że relacja site nie jest brana pod uwagę w renderze do wyświetlenia.

http://www.openstreetmap.org/changeset/50476425
http://www.openstreetmap.org/changeset/50477207
http://www.openstreetmap.org/changeset/50477523
http://www.openstreetmap.org/changeset/50477603

http://www.openstreetmap.org/changeset/50478062
http://www.openstreetmap.org/relation/7412705

relacje site nie są używane w większości (wszystkich?) renderów.

Teoretycznie relacja site jest w proposed także nie ma się co dziwić, że jej wykorzystanie na dzień dzisiejszy jest niewielkie. Ale co w takim razie użyć jak nie ją?

Swoją drogą miał miejsce głos http://www.openstreetmap.org/changeset/50477016 zauważający, że używamy tagów na dzień dzisiejszy nie używanych, tudzież nieudokumentowanych. Oczywiście są one do opisania, ale tak myślę że gdzie mamy area=not applicable oraz size=not applicable by wyrzucić te zapisy całkiem. W sumie są tam jedynie dla ułatwienia porównywalności z oryginalną bazą, ale de facto przydatnych informacji jako takie nie wnoszą.

Akurat tutaj pasuje.

Niemal wszystkie site które widziałem można zastąpić przez multipolygon. Jednak jeśli potrzebujemy zbiór punktów to z tego co wiem to jest tylko type=site.

Nie wgłębiałem się w szczegóły techniczne, ale iD oferuje typ relacji “collection”.

“Relation to represent all the ways making up” - też nie na punkty (https://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways).

Zostałem przy site jako jednak tej wprost wskazującej na to co potrzebujemy i ciężo znaleźć coś bardziej odpowiedniego. Mam już przygotowane dane do importu http://bigvo.hopto.org/osm-extra/lubelskie5_bez.zip Wyrzuciłem z nich kilka pomników z lokalizacjami Adonis Vernalis jako że roślina ta jest jest na liście gatunków chronionych CITES, a swego czasu uznaliśmy że gatunków pod ochroną na mapę nie nanosimy. Jeśli pod tym względem nastąpiła zmiana to oczywiście w każdej chwili będzie można do tego wrócić.
Co do danych to mam jedną poważna wątpliwość a jest nią parametr size. Nie byłem pewny jak to ugryźć by zachować pewną spójność z oryginalnymi danymi http://bigvo.hopto.org/osm-extra/lubelskie2_bez.zip Parametr ten dotyczy się głazów i kamieni i zwykle wyraża obwód oraz wysokość i pozostawiłem je w jednym parametrze size. W OSM natomiast przy dwóch wartościach size pierwsza winna być długością a nie obwodem http://wiki.openstreetmap.org/wiki/Key:size.

Wszelkie uwagi co po powyższego problemu jak i innych mile widziane. Tym czasem zrobię kolejne podejście do wyświetlania tych danych na carto. A nóż coś się z tego urodzi. Jeśli w międzyczasie nie odezwie się kolega tomalos spróbuję bezpośrednio zadzwonić do GDOŚ by ustalić formę kontaktu w sprawie oficjalnego udostępnienia danych.

Czy ktoś się orientuje jakie właściwie są granice rezerwatu Tobolinka i gdzie można je sprawdzić?

http://www.openstreetmap.org/way/384182490
http://www.openstreetmap.org/way/404258295

w/g tej strony http://bozena-giby.republika.pl/rezerwaty.htm “W skład rezerwatu wchodzi dystroficzne jezioro Tobolinka (notabene podwójne) wraz z pasem boru bagiennego, o szerokości 3-5 metrów” w/g http://mapy.geoportal.gov.pl/imap/?gpmap=gp0&actions=acShowServices_KATASTER , https://pl.wikipedia.org/wiki/Rezerwat_przyrody_Tobolinka potwierdzają wersję z opisu pozatym powierzchnię rezerwatu ok. 4,5ha można samemu sprawdzić otwieramy geoprtal klikamy prawym, wybieramy “mierz powierzchnię” po kilku klinkieciach znamy odpowiedź.
Wyglada na to że http://www.openstreetmap.org/way/384182490#map=16/54.0276/23.4036 jest błędne:

  1. To nie park narodowy (dużego wyboru nie ma https://pl.wikipedia.org/wiki/Parki_narodowe_w_Polsce))
  2. powerzchnia o wiele za duża zamiast ok. 4,5ha tutaj widać ponad 22ha (można dokładnie sprawdzić w geoportalu)
  3. Nie znalazłem potwierdzenia dla tej wiersji.

Poniżej podaję link do strony geoserwisu GDOŚ z referencyjnymi granicami obszarów chronionych w tym rezerwatów przyrody. Wspomniane granice można pobrać również w formie wektorwej w formacie .shp

http://geoserwis.gdos.gov.pl/mapy/?extent=788222.689146,693513.320591,788730.160994,693763.881509&addLayers=&mapNr=0&styleMask=013013113013013013113013013013

Dzięki! To się pewnie przyda, bo w niektórych miejscach widać podwójne granice, czyli ktoś zrobił na oko, a kto inny nie sprawdził jak wrzucał dokładniejsze dane - albo odwrotnie. Mam nadzieję, że niedługo uda się wdrożyć wyświetlanie obszarów chronionych w osm-carto, to będzie widać takie duplikaty i trzeba będzie to powoli czyścić.

rozumiem ze na obecną chwile pojęcie “otuliny parku krajobrazowego” w openstreetmaps nie funkcjonuje i rysujemy samą granicę parku, czy tak ?

Tak. Informacje o otulinie nie są nam do niczego potrzebne.