Ekipa poinformowana https://lists.openstreetmap.org/pipermail/imports/2016-June/004450.html choć już widzę, że tak się namęczyłem by dodać odpowiednie szczegóły, że pominąłem tag główny leisure=nature_reserve O.O Poczekam z dwa dni na ewentualne sugestie z listy mailingowej i dodam i jego.
Głos z zza granicy nie jest zbyt pochlebny https://lists.openstreetmap.org/pipermail/imports/2016-June/004451.html . Największy problem kolega Frederik ma z niemożliwością weryfikacji w terenie granic użytków co jak rozumiem wg niego nie jest w OSM potrzebne gdyż tych danych nie można w żaden sposób poprawiać oglądając je w terenie gdyż są one nie weryfikowalne. Jak dla mnie to wszystkie granice są tworem czysto wirtualnym i politycznym. Cały szereg nawet granic państwowych nie może być zweryfikowany w terenie jak choćby granica pomiędzy Marokiem a Saharą Zachodnią. Piasek po każdej jego stronie wygląda tak samo. Zresztą nikt nie miał większego wpływu na to niż Niemcy by taką wirtualną granicą była nawet zewnętrzna granica Shengen.
Kolejna istotna obiekcja to, że nie można tych danych uzupełnić. A kto by potrzebował uzupełniać kompletne dane gdy nawet te które tego wymagają często nie są?
Odpowiedź na kwestię polygonów wydaje się oczywista. Tak są powiązane przynajmniej tą samą uchwałą je ustanawiającą.
Na koniec jednak najsensowniejsze pytanie po co nam to. Ja bym w tym miejscu puścić daleko wodze fantazji i wizjonerskie przykłady, czy górnolotne założenia o współpracy środowiska OSM z jednostkami urzędowymi ale czy o to chodzi? Jakie jest wasze zdanie?
A co to jest? Nie ma tam żadnych tagów, tylko punkty i linie.
Moim zdaniem należy kolegę Frederika zignorować i robić swoje. Wyraził swoje zdanie i tyle.
Z mojego punktu widzenia bardzo ciekawa jest możliwość wykorzystania danych o drzewach do wizualizacji 3D. Mam nadzieję, że ktoś się za to zabierze bo można naprawdę bardzo dobre efekty uzyskać przypisując różnym gatunkom drzew różne odcienie zieleni i różną geometrię.
@maraf24 te punkty i linie w zdecydowanej ilości przypadków łączą się w relacje. By nie dublować danych to nie przypisuje się się ich do punktów tylko właśnie określa w relacjach z których zastosowaniem mapnik czy każdy inny dobrze napisany twór sobie z nimi radzi i z nich skorzysta. Choćby w przykładzie z listy dyskusyjnej widać jakie tagi zostały dodane http://www.openstreetmap.org/relation/6298112
@marek kleciak
No to jest jasne, że kwestia importu pomników przyrody obroni się sama gdyż żaden z przytoczonych przez Frederika argumentów nie będzie miał wówczas zastosowania, ale w tym przypadku gdzie mowa o granicach obszarów użytków ekologicznych nie wydaje mnie się że można tak po prostu zignorować i wypada dość sensownie odpowiedzieć
Niech mi Frederik pokaże np w Nepalu płot ograniczający park narodowy.
Jakikolwiek. Albo tabliczkę z napisem: tutaj jest ładny widok (tourism=viewpoint). Nie w każdej sytuacji są to informacje widoczne w terenie.
Dobry jest Twój przykład z granicami państw. Również granice województw są widoczne jedynie jako tabliczki przy drogach głównych.
Dla mnie to jałowa dyskusja wynikająca z przyjętej przez Frederika ideologii pod tytułem: importy są be.
Panowie z listy z importami wydaje się pogodzili się z faktem dokonania importu granic, choć winny im jeszcze jestem wyjaśnienie w kwestii definicji i konieczności wartości tagu kodinspire. Niemniej można by ruszyć z importem pomników przyrody by mieć gotowce do przedstawienia na liście.
@tomalos
Udało się już przygotować pliki z pomnikami przyrody? Te dostępne na stronie GDOŚ na stronie nadal posiadają jedynie część informacji
@rmikke
Miałeś może chwilę by przysiąść nad skryptem weryfikującym zmiany pomiędzy bazami OSM i GDOŚ?
Sorry, ja wprawdzie programować ogólnie potrafię, ale mam niemal zerową praktykę w programowaniu aplikacji webowych, nie znam PHP, a javascriptem bawiłem się prawie 20 lat temu. API OSM też nie umiem. Czyli - jestem w stanie zaprojektować dobry algorytm, ale pojęcia nie mam, jak go zakodować.
W sumie to chętnie bym się nauczył i mam to w planach, ale na bliżej nieokreśloną przyszłość, skoro praktycznie nie mam podstaw.
A co w z tymi brakującymi tagami w tych importach? Jak rozumiem, wszędzie powinno tam być boundary=protected_area, a gdzieniegdzie można dodać leisure=nature_reserve - w zależności od protect_class?
boundary=protected_area faktycznie wypadało by dać. Szkoda, że nikt tego wcześniej nie zauważył. Co do leisure=nature_reserve to uważam, że do każdego winno się go dodać i jak rozumiem to głosy są raczej zgodne co do tego że korzysta właśnie z takiej informacji wraz z protect_class https://lists.openstreetmap.org/pipermail/imports/2016-July/004459.html oraz https://lists.openstreetmap.org/pipermail/imports/2016-July/004460.html . Natomiast renderowi zostawił bym decyzję czy taki obszar z leisure=nature_reserve i protect_class<7 czy wyświetlać czy nie i od którego zbliżenia.
-
Ciekawe “nazwy” mają niektóre obszary chronione:
“Bagno przy ul. Poznańskiej”
“Białe Błoto 207 c”
“Czesława Łaszka - użytek 624”
“Kompleks leśny z oczkami wodnymi”
“Obszar na terenie Nowej Karczmy we Wrocławiu”
“Paprocie serpentynitowe w Masywie Ślęży stanowisko nr 1” (i 2,3, aż do 10)
“Podmokła łąka przy ul. Poznańskiej”
“Półotwarta powierzchnia leśna”
“Stanowisko występowania sasanki łąkowej”
“Torfowisko śródleśne koło miejscowosci Mocha”
“Wyspa na jeziorze Duże Dormowskie”
“użytek 151”
“użytek 152”
“użytek 154” itp.
“DWIE WYSPY NA JEZIORZE LUTOL”
“Dwa zbiorniki wodne wraz z otaczającym obszarem leśnym na terenie Janówka” -
Wygląda na to, że granice administracyjnie sztucznie dzielą obszary. Tutaj http://www.openstreetmap.org/#map=17/51.23707/17.41730 między modkradłami po lewej i prawej nie ma żadnej przerwy, jest za to granica.
-
Tutaj http://www.openstreetmap.org/#map=16/51.2489/17.4820 obszar dzieli granica i chyba strumień. Może formalnie tak jest, ale w praktyce taki wąski odstęp to żaden odstęp.
Użyta tu jest też relacja type=multipolygon. Właściwsza wydaje mi się type=boundary, pasująca do boundary=protected_area. Nie wiem jednak, czy to ma jakieś praktyczne znaczenie.
Cchesz powiedzieć, ze GDOŚ źle wytyczyło i nazwało obszary?
- GDOŚ niczego nie nazwało. Skopiowało określania z dostępnych źródeł. Wiekszość to były nazwy, reszta to coś, co wygląda na ref albo na opis.
Akurat u siebie mam dwa takie przypadki:
“Obszar na terenie Nowej Karczmy we Wrocławiu” - i to jest obszar na terenie Nowej Karczmy we Wrocławiu
oraz “Dwa zbiorniki wodne wraz z otaczającym obszarem leśnym na terenie Janówka” - i to są dwa zbiorniki z lasem na terenie Janówka.
Nawet mam dokument z którego wzięto te określania, nigdzie tam nie podano, że to są nazwy. Po prostu musiano jakoś określić nienazwane obszary i zrobiono to w taki sposób, a GDOŚ to skopiował. Nie czyni to z nich nazw w OSM. W tym dokumencie są też inne takie “nazwy”, np. pomnik przyrody “1 szpaler drzew”. Szczęśliwie tego nie skopiowali.
- GDOŚ niczego nie wytyczało. Granice wzięli pewnie z odpowiednich aktów prawnych, które musiały - dla wygody - posługiwać numerami działek. Tak wnioskuje z przypadku Ols Sokołowickich - ten strumień jest wydzielony w katastrze i tak właśnie idzie granica tego użytku.
A przecież tu chodzi o las. Jest to więc pewnego rodzaju fikcja.
Ten przypadek podałem jako ciekawostkę - nie sugeruję, że coś tu jest źle w danych. Natomiast z punktu widzenia ochrony przyrody określiłbym to jako błąd - bo obszar tego strumienia powinien być włączony do obszaru chronionego. Ale tu już problem GDOŚ.
OMG jak widzisz coś nie tak w danych które posiadają i udostępnili to im zgłoś
Nawiązując do dyskusji w wątku z pytaniami ogólnymi https://forum.openstreetmap.org/viewtopic.php?pid=651025#p651025 to dzięki pracy kolegi tomalosa mamy do dyspozycji pliki z pełnymi danymi pomników przyrody dla województw lubelskiego i łódzkiego. Zawierają one poniższe tabele
Data_utw - data ustanowienia obiektu pomnikiem przyrody
Dzial_och - wykonywane działania ochronne
ID_OST - kolejny numer ID
Lcz_ob - liczba obiektów w grupie jeśli jest to np. skupisko czy aleja drzew (liczba się powtarza przy szeregu obiektów w grupie gdyż każdy obiekt jest zaznaczony z osobna)
igl_lis_in - oznaczenie obiektu jako drzewo iglaste/liściaste/ nie dotyczy
Naz_lc - nazwa gatunku/odmiany łacińska
Naz_pol - nazwa gatunku/odmiany polska
Nazwa_pomn - imię własne obiektu
Opis - opis
Opis_lokal - krótki opis lokalizacji obiektu
Ozn - informacja czy obiekt oznakowany jest prawidłowo [brak informacji/nieoznakowany/oznakowany/niezgodnie z rozporządzeniem/oznakowany, zgodnie z rozporządzeniem]
Piersnica - obwód drzewa na wysokości 1,3m
Poj_skup - pojedynczy obiekt czy w skupisku
Pow - powierzchnia obiektu
Rodzaj_po - rodzaj pomnika przyrody [aleja/drzewo/grupa drzew/głaz narzutowy/inny/krzew/skałka/wodospad/źródło]
Uwagi - nieco szerszy opis obiektu
Wysokosc - wysokość
Zagr - opis zagrożeń dla obiektu, np niewielka odległość od drogi, budynku itp.
Zywa_nieoz - [przyroda nieożywiona/przyroda żywa]
dl_sze_wy - wartości określające wielkość
zdrowie - wartości określające stan zdrowia [brak informacji/0/1/2/3]
Jak dla mnie można by je użyć w następujący sposób, gdzie wpisałem null dla danych których IMHO nie ma potrzeby importować
Data_utw - established
Dzial_och - NULL
ID_OST - ref:gdoś
Lcz_ob - plant_count wydaje się najbardziej odpowiedni choć póki co należy jedynie do proposed
igl_lis_in - leaf_type
Naz_lc - species
Naz_pol - species:pl
Nazwa_pomn - name z tym, że jak dla mnie jeśli brakuje name to by wstawić za wartość “pomnik przyrody” by odróżnić od okazałych drzew dla których warto dodać denotation=natural_monument lecz nie są one pomnikami przyrody w myśl ustawy
Opis - description
Opis_lokal - description:location
Ozn - information=sign & sign=proper/inproper/unsigned
Piersnica - circumference tu się zapytam czy by nie rozważyć innego oznaczenia wracając do przytoczonego wcześniej wywodu o różnicy pomiędzy OSMowym 1m a Polskim 1,3m https://forum.openstreetmap.org/viewtopic.php?pid=594852#p594852
Poj_skup - ?? nie mam pomysłu na tag a wydaje się pomocny choćby dla łatwego wyszukiwania tylko obiektów np. pojedynczych
Pow - size
Rodzaj_po - natural
Uwagi - note
Wysokosc - height
Zagr - NULL
Zywa_nieoz - animate
dl_sze_wy - size
zdrowie - vitality
Liczę na uwagi, a przy okazji na koniec zapytam również o legalność wykorzystania danych GDOŚ. Czy pismo w sprawie ich wykorzystania od GDOŚ mam pisać ja jako szeregowy mapowicz czy też można liczyć, że wyśle go stowarzyszenie jako strona odpowiedniejsza w tej kwestii. Oczywiście treść pisma mogę przygotować do uzgodnienia. Być może na spotkaniu?
- ID_OST - ref:gdoś
polskie literki mogą być w nazwie klucza?
- Nazwa_pomn - name z tym, że jak dla mnie jeśli brakuje name to by wstawić za wartość “pomnik przyrody” by odróżnić od okazałych drzew dla których warto dodać denotation=natural_monument lecz nie są one pomnikami przyrody w myśl ustawy
Wg wiki denotation=landmark mamy dla okazałych drzew
denotation=natural_monument przyjęło się dla pomników przyrody, czasem dodaje się protected=yes dla jasności
“pomnik przyrody” to nie nazwa
- Piersnica - circumference tu się zapytam czy by nie rozważyć innego oznaczenia wracając do przytoczonego wcześniej wywodu o różnicy pomiędzy OSMowym 1m a Polskim 1,3m https://forum.openstreetmap.org/viewtopic.php?pid=594852#p594852
circumference_13 ?
- Poj_skup - ?? nie mam pomysłu na tag a wydaje się pomocny choćby dla łatwego wyszukiwania tylko obiektów np. pojedynczych
cluster?
- Pow - size
area?
- Uwagi - note
To by zależało od rodzaju tych uwag. Tag note to informacja dla innych mapperów.
- dl_sze_wy - size
size ok, ale było już przy pow 
3 - O to circumference to jeszcze zapytam na liście talk z importami, chyba że do tego czasu dość jednoznacznie opowiemy się za konkretnym przykładem
4 - Pomysł dobry, będzie można za wartości dać [yes/no].
5 i 7 są o tyle ciekawe że obiekty które są przestrzenne nie są płaskie więc z reguły nie powinny się rozmiary powtarzać i jeśli istnieje dla jednego jedna wartość to druga zwykle na tyle ile przeglądnąłem zawiera “nie dotyczy” stąd pomysł by użyć tego samego oznaczenia, ale fakt jedną jako area drugą jako size będzie łatwiej użyć. Z tym że takie area zwróci przy tym uwagę panów na liście, gdyż w 99% przypadków nie używano nic innego jak area=yes, choć to akurat będzie łatwo obronić. Większość budynków oznacza się jako building=yes co wcale nie oznacza, że jest to opis wystarczający i pełny.
denotation=landmark to tak nie do końca. Jak dla mnie to taki obiekt musi w sposób jednoznaczny z otoczenia się wybijać a drzew o rozmiarach pomnikowych wg ekologów jest w takich Bieszczadach pewnie ze 20 tyś a wcale na landmark nie zasługują gdyż giną w tłumie pozostałych. Takie drzewa często są w bazach jak ta http://www.rpdp.hostingasp.pl. Na landmark jak dla mnie zasługują jedynie największe pomniki przyrody i mogło by to być 5 może 10 obiektów na województwo tak by jak będę jechał drogą wiedzieć że tu muszę nadłożyć 10km gdyż w okolicy będzie naprawdę okazały obiekt.
Argumentem przeciw name=pomnik przyrody było dotychczas, że źle to wygląda dla skupisk drzew. Owszem nie najlepiej, ale tu można zamiast nazywać każde pojedyncze to powiązać daną grupę relacją http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster i nazwę pomnik przyrody umieścić tam.
Zastanawiam się, czy niektóre z tych pól nie powinny być poprzedzonego przedrostkiem “gdos:”.
Np. gdos:circumference - bo wszak aktualny obwód pewnie już się zmienił i ktoś może chcieć wpisać aktualny. Byłoby łatwo wykryć różnicę.
Podobnie gdos:height.
A gdos:area nie mieszałoby się z area w sensie osm.
To w tym pliku z pomnikami przyrody są także obiekty nie będące pomnikami, ale tylko okazałe?
Odwrotnie. W tej bazie (gdosiu) mamy tylko pomniki przyrody. Natomiast w realu rosną sobie również drzewa o rozmiarach pomnikowych, które równie dobrze zasługują na oznaczenie jako denotation=natural_monument, ale jako takie pomnikiem przyrody nie są gdyż żadna gmina ich jako pomnik przyrody nie uchwaliła. Sam mam takie kilka sztuk w gminie. Nazwanie pomnika pomnikiem pomogło by je rozróżnić. Inna całkiem baza jak http://www.rpdp.hostingasp.pl/ zawiera zarówno drzewa które są pomnikami przyrody jak i te które o to miano jedynie zasługują i jak powiedziałem nie jest to całkiem małą liczbą.
Przyjęte jest raczej zastosowanie odwrotnej kolejności circumference:gdos, ale i tak pomysłowi jestem przeciw. Już lepiej dodać source=Generalna Dyrekcja Ochrony Środowiska a dla circumference i height śledzić zmiany tak by zachować spójność pomiędzy bazami gdoś a osm i przekazywać informacje o zmianach do GDOŚ do weryfikacji.
Czemu nie? Lepiej by było poprawnie, UTF-8 i tak jest już wspierane w tagach…