Ochrona przyrody

maraf24 · 2017-06-26 23:52:18

1. ID_OST - ref:gdoś

polskie literki mogą być w nazwie klucza?

2. 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

3. 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/viewtop … 52#p594852

circumference_13 ?

4. Poj_skup - ?? nie mam pomysłu na tag a wydaje się pomocny choćby dla łatwego wyszukiwania tylko obiektów np. pojedynczych

cluster?

5. Pow - size

area?

6. Uwagi - note

To by zależało od rodzaju tych uwag. Tag note to informacja dla innych mapperów.

7. dl_sze_wy - size

size ok, ale było już przy pow

wmyrda · 2017-06-27 09:39:12

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/Rela … ed/Cluster i nazwę pomnik przyrody umieścić tam.

maraf24 · 2017-06-27 12:28:14

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.

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.

To w tym pliku z pomnikami przyrody są także obiekty nie będące pomnikami, ale tylko okazałe?

wmyrda · 2017-06-27 14:11:31

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ą.

maraf24 wrote:

gdos:circumference

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.

Last edited by wmyrda (2017-06-27 14:12:13)

Mateusz Konieczny · 2017-06-27 16:29:33

maraf24 wrote:

1. ID_OST - ref:gdoś
polskie literki mogą być w nazwie klucza?

Czemu nie? Lepiej by było poprawnie, UTF-8 i tak jest już wspierane w tagach...

Last edited by Mateusz Konieczny (2017-06-27 16:30:07)

maraf24 · 2017-06-27 23:39:58

wmyrda wrote:

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.[...]

W takiej sytuacji proponuję używać do tego tagu protected=no.

Przyjęte jest raczej zastosowanie odwrotnej kolejności circumference:gdos, ale i tak pomysłowi jestem przeciw.

W przypadku popularnych tagów - tak (poza name). Przy całkiem nowych jest to sprawa umowna.

Już lepiej dodać source=Generalna Dyrekcja Ochrony Środowiska a dla circumference

Nie lubię samego source bo nie za bardzo wiadomo, czy odnosi się do wszystkich, czy do niektórych tagów.
Poza tym jak ktoś w iD zmieni np. height, to nawet nie zauważy, że jest jakieś source. Trzeba by analizować historię zmian, by odkryć, co pochodzi z importu a co potem zmieniono.

marek kleciak · 2017-06-28 05:32:54

Mamy tag np. source:geometry, więc da się to doprecyzować...

wmyrda · 2017-06-28 07:50:51

maraf24 wrote:

W takiej sytuacji proponuję używać do tego tagu protected=no.

ma sens

maraf24 wrote:

Poza tym jak ktoś w iD zmieni np. height, to nawet nie zauważy, że jest jakieś source. Trzeba by analizować historię zmian, by odkryć, co pochodzi z importu a co potem zmieniono.

kolego maraf24 pan to problemy chyba na siłę szuka. No i co że trzeba sprawdzać rozbieżności? Jak trzeba to należy to zrobić, a możliwości ku temu są kwestia odpowiedniej decyzji i działań. Że tak zacytuję kolegę gsapijaszko z innego wątku odnoszącego się dokładnie tdo tego tematu https://forum.openstreetmap.org/viewtop … 30#p651030

gsapijaszko wrote:

Kolega nie ma problemu z dzieleniem się swoją pracą... Nie ma problemu, by napisać skrypt/aplikację/bazę, która będzie sprawdzała dwa (lub więcej) źródeł danych. Problem jest, jak rozumiem, ze stwierdzeniem, które dane są poprawne. i znaleziem wspólnego dla nich wyznacznika.

Widzę to tak:
Także nie mnóżmy tych samych tagów i po kilka razy nie wpisujmy tej samej wartości jak height w różnych polach tylko po to by w bazie mieć kilka różnych wartości dla tego samego. Wartość poprawna jest jedna tylko i wyłącznie. GDOŚ nie bierze danych z powietrza tylko wpierw ktoś dokonał odpowiednich pomiarów i ma na to zdjęcia czy inne dokumenty. Jak ktoś będzie chciał dane w OSM zmienić odnośnie parametrów obiektów wprowadzonych na podstawie danych GDOŚ to należy je śledzić i pytać autora zmian o potwierdzenie na jakiej podstawie zmienił te wartości. Jeśli je potwierdzi to pozostawić je w bazie i przesłać do GDOŚ by je u siebie również zweryfikowali. Jeśli nie przywrócić stan poprzedni.

Także nie utrudniajmy sobie mnożąc tagi po naszej stronie, gdzie i tak trzeba będzie śledzić każdy tag i to zarówno height, height:gdoś, height:jawiemlepiej, czy height:2017 by wiedzieć czy nie został on zmieniony.

maraf24 wrote:

W przypadku popularnych tagów - tak (poza name). Przy całkiem nowych jest to sprawa umowna.

No więc po co robić odwrotnie niż jest przyjęte dla popularnych tagów? Dla mnie ref:gdoś=

maraf24 · 2017-06-28 10:33:49

wmyrda wrote:

maraf24 wrote:
Poza tym jak ktoś w iD zmieni np. height, to nawet nie zauważy, że jest jakieś source. Trzeba by analizować historię zmian, by odkryć, co pochodzi z importu a co potem zmieniono.
kolego maraf24 pan to problemy chyba na siłę szuka.

To jest dyskusja, którą sam zainicjowałeś. Na tym właśnie ona polega.
Poza tym lepiej być mądrym przed szkodą.

wmyrda wrote:

maraf24 wrote:
W przypadku popularnych tagów - tak (poza name). Przy całkiem nowych jest to sprawa umowna.
No więc po co robić odwrotnie niż jest przyjęte dla popularnych tagów? Dla mnie ref:gdoś=

To chyba jest logiczne, że jeśli tagi są nowe, nie można ustalić ich popularności. W takiej sytuacji nie jest możliwe zastosowanie reguły "najpierw popularniejszy tag".

Dla uzupełnienia: "gdos", który to proponowałem, nie miał być tagiem, ale oznaczeniem przestrzeni nazw. W OSM jest on prefiksem.

Last edited by maraf24 (2017-06-28 10:37:16)

wmyrda · 2017-06-28 11:04:23

maraf24 wrote:

To jest dyskusja, którą sam zainicjowałeś. Na tym właśnie ona polega.
Poza tym lepiej być mądrym przed szkodą.

Tak ale nie szukajmy problemów na siłę i jeszcze niepotrzebnie dodatkowo sobie sami nie utrudniajmy. Wyszukiwanie “denotation=natural_monument AND height=* in Poland” w overpass wykazało, że takich obiektów mamy na dziś w bazie OSM 70. Do tego przy wyrywkowym sprawdzeniu około 20 z nich żaden z nich nie miał zmienionej wartości height czy circuference. Tym samym nie widzę potrzeby by mnożyć identyczne tagi i jeszcze dodawać im wartości, których nikt poza wtajemniczonymi nie wykorzysta, a zwykłe height bez przedrostków jest szansa, że będzie działać nawet dla wizualizacji przygotowanej dla np. Wenezueli gdzie nikt nie zgadnie, że ktoś w Polsce specjalnie mu zadanie utrudnił.

maraf24 wrote:

To chyba jest logiczne, że jeśli tagi są nowe, nie można ustalić ich popularności. W takiej sytuacji nie jest możliwe zastosowanie reguły "najpierw popularniejszy tag".

To chyba niepoważnie mówisz. ref nie jest nowym tagiem i jest bardzo popularnym. W takich sytuacjach dodatkowo w tagu można zawrzeć skąd się go bierze czyli w tym wypadku ref:godś. Celowo stosuję tu nie samo ref, gdyż można mieć jako źródło również bazę INSPIRE i tym samym mieć ref:inspire. Dodatkowym plusem jest to, że oba refy są wówczas obok siebie.

DO WSZYSTKICH
Liczę, że ktoś wypowie się co do jednego z pierwotnie zadanych pytań a mianowicie kwestie legalności użycia danych i strony która miała by wystosować pismo do GDOŚ

EDIT: Na liście dyskusyjnej trwa obecnie rozmowa na temat importu informacji o drzewach w mieście Ottawa https://lists.openstreetmap.org/piperma … 05047.html i okazuje się, że problem circumference już nie istnieje, gdyż za takowy uważa się obecnie standardowo właśnie pomiar na wysokości 1,3m co również zostało odzwierciedlone na wiki https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

Last edited by wmyrda (2017-06-28 13:14:42)

maraf24 · 2017-06-28 21:21:38

wmyrda wrote:

maraf24 wrote:
To chyba jest logiczne, że jeśli tagi są nowe, nie można ustalić ich popularności. W takiej sytuacji nie jest możliwe zastosowanie reguły "najpierw popularniejszy tag".
To chyba niepoważnie mówisz. ref nie jest nowym tagiem i jest bardzo popularnym. W takich sytuacjach dodatkowo w tagu można zawrzeć skąd się go bierze czyli w tym wypadku ref:godś. Celowo stosuję tu nie samo ref, gdyż można mieć jako źródło również bazę INSPIRE i tym samym mieć ref:inspire. Dodatkowym plusem jest to, że oba refy są wówczas obok siebie.

Poważnie, poważnie.
Twój przykład z ref jest zupełnie nieadekwatny do tego, co napisałem, bo ref nie jest nowym tagiem, a popularnym.

DO WSZYSTKICH
Liczę, że ktoś wypowie się co do jednego z pierwotnie zadanych pytań a mianowicie kwestie legalności użycia danych i strony która miała by wystosować pismo do GDOŚ

tomalos zdaje się pisał, że jest na to zgoda. Chodzi o to, by mieć to na papierze?

Idąc dalej:

1. Jak zrozumiałem, masz te dane z gdoś. Czy mógłbyś utworzyć 1-2 przykładowe węzły z danymi z nimi i podać tu linki do nich? Taki przykład może by też zachęcił innych do wypowiedzi.
2. Ile jest obiektów do zaimportowania dla tych dwóch województw?
3. Czy masz pomysł jak rozwiązać kwestię duplikowania się danych zaimportowanych z tymi obecnymi już w OSM, przy czym należy uwzględnić, że pomniki przyrody mogą nie być prawidłowo otagowane, tj. nie mieć denotation=natural_monument ale np. name="Pomnik przyrody". Co zrobić w przypadku różnicy w lokalizacji?

wmyrda · 2017-06-28 23:14:50

maraf24 wrote:

Poważnie, poważnie.
Twój przykład z ref jest zupełnie nieadekwatny do tego, co napisałem, bo ref nie jest nowym tagiem, a popularnym.

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

maraf24 wrote:

tomalos zdaje się pisał, że jest na to zgoda. Chodzi o to, by mieć to na papierze?

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.

maraf24 wrote:

1. Jak zrozumiałem, masz te dane z gdoś. Czy mógłbyś utworzyć 1-2 przykładowe węzły z danymi z nimi i podać tu linki do nich? Taki przykład może by też zachęcił innych do wypowiedzi.

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.

maraf24 wrote:

2. Ile jest obiektów do zaimportowania dla tych dwóch województw?

9175 - Łódzkie
5176 - Lubelskie

maraf24 wrote:

3. Czy masz pomysł jak rozwiązać kwestię duplikowania się danych zaimportowanych z tymi obecnymi już w OSM,

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...

maraf24 wrote:

pomniki przyrody mogą nie być prawidłowo otagowane, tj. nie mieć denotation=natural_monument ale np. name="Pomnik przyrody".

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

maraf24 wrote:

Co zrobić w przypadku różnicy w lokalizacji?

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.

rmikke · 2017-06-29 07:02:28

wmyrda wrote:

maraf24 wrote:
Co zrobić w przypadku różnicy w lokalizacji?
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.

rmikke · 2017-06-29 07:11:20

wmyrda wrote:

Tak ale nie szukajmy problemów na siłę i jeszcze niepotrzebnie dodatkowo sobie sami nie utrudniajmy. Wyszukiwanie “denotation=natural_monument AND height=* in Poland” w overpass wykazało, że takich obiektów mamy na dziś w bazie OSM 70. Do tego przy wyrywkowym sprawdzeniu około 20 z nich żaden z nich nie miał zmienionej wartości height czy circuference. Tym samym nie widzę potrzeby by mnożyć identyczne tagi i jeszcze dodawać im wartości, których nikt poza wtajemniczonymi nie wykorzysta, a zwykłe height bez przedrostków jest szansa, że będzie działać nawet dla wizualizacji przygotowanej dla np. Wenezueli gdzie nikt nie zgadnie, że ktoś w Polsce specjalnie mu zadanie utrudnił.

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.

Last edited by rmikke (2017-06-29 07:14:51)

marek kleciak · 2017-06-29 08:09:57

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

Tree trunks are measured at the height of an adult's breast. However, this is defined differently in different countries and situations. In continental Europe, the UK, and Canada the diameter is measured at 1.3 metres above ground.[1] In the US, Australia, New Zealand, Burma, India, Malaysia, and South Africa, breast height diameter is measured at a height of 1.4 metres. Previously 4.5 ft (1.37 m) was used.

Last edited by marek kleciak (2017-06-29 08:14:58)

wmyrda · 2017-06-29 08:20:47

@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/piperma … 05050.html
- https://wiki.openstreetmap.org/wiki/Key:circumference
https://lists.openstreetmap.org/piperma … 05057.html
- https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

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.

Last edited by wmyrda (2017-06-29 08:23:24)

rmikke · 2017-06-29 08:47:05

wmyrda wrote:

@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/piperma … 05050.html
- https://wiki.openstreetmap.org/wiki/Key:circumference
https://lists.openstreetmap.org/piperma … 05057.html
- https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
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.

Last edited by rmikke (2017-06-29 08:49:53)

wmyrda · 2017-06-29 10:08:51

rmikke wrote:

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.

maraf24 wrote:

Czy mógłbyś utworzyć 1-2 przykładowe węzły z danymi z nimi i podać tu linki do nich? Taki przykład może by też zachęcił innych do wypowiedzi.

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ę.

wmyrda · 2017-07-23 08:46:29

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

Last edited by wmyrda (2017-07-23 10:44:07)

Mateusz Konieczny · 2017-07-23 17:45:36

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

wmyrda · 2017-07-23 18:29:44

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ą.

Mateusz Konieczny · 2017-07-23 19:31:42

wmyrda wrote:

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ą?

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.

rmikke · 2017-07-23 22:56:36

Mateusz Konieczny wrote:

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".

Mateusz Konieczny · 2017-07-24 12:17:39

rmikke wrote:

Mateusz Konieczny wrote:
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/Rel … ected_Ways).

wmyrda · 2017-07-25 17:05:17

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.

Announcement

#76 2017-06-26 23:52:18

Re: Ochrona przyrody

#77 2017-06-27 09:39:12

Re: Ochrona przyrody

#78 2017-06-27 12:28:14

Re: Ochrona przyrody

#79 2017-06-27 14:11:31

Re: Ochrona przyrody

#80 2017-06-27 16:29:33

Re: Ochrona przyrody

#81 2017-06-27 23:39:58

Re: Ochrona przyrody

#82 2017-06-28 05:32:54

Re: Ochrona przyrody

#83 2017-06-28 07:50:51

Re: Ochrona przyrody

#84 2017-06-28 10:33:49

Re: Ochrona przyrody

#85 2017-06-28 11:04:23

Re: Ochrona przyrody

#86 2017-06-28 21:21:38

Re: Ochrona przyrody

#87 2017-06-28 23:14:50

Re: Ochrona przyrody

#88 2017-06-29 07:02:28

Re: Ochrona przyrody

#89 2017-06-29 07:11:20

Re: Ochrona przyrody

#90 2017-06-29 08:09:57

Re: Ochrona przyrody

#91 2017-06-29 08:20:47

Re: Ochrona przyrody

#92 2017-06-29 08:47:05

Re: Ochrona przyrody

#93 2017-06-29 10:08:51

Re: Ochrona przyrody

#94 2017-07-23 08:46:29

Re: Ochrona przyrody

#95 2017-07-23 17:45:36

Re: Ochrona przyrody

#96 2017-07-23 18:29:44

Re: Ochrona przyrody

#97 2017-07-23 19:31:42

Re: Ochrona przyrody

#98 2017-07-23 22:56:36

Re: Ochrona przyrody

#99 2017-07-24 12:17:39

Re: Ochrona przyrody

#100 2017-07-25 17:05:17

Re: Ochrona przyrody

Board footer