W takiej sytuacji proponuję używać do tego tagu protected=no.
W przypadku popularnych tagów - tak (poza name). Przy całkiem nowych jest to sprawa umowna.
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.
Mamy tag np. source:geometry, więc da się to doprecyzować…
ma sens
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/viewtopic.php?pid=651030#p651030
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.
No więc po co robić odwrotnie niż jest przyjęte dla popularnych tagów? Dla mnie ref:gdoś=
To jest dyskusja, którą sam zainicjowałeś. Na tym właśnie ona polega.
Poza tym lepiej być mądrym przed szkodą.
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.
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ł.
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/pipermail/imports/2017-June/005047.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
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.
tomalos zdaje się pisał, że jest na to zgoda. Chodzi o to, by mieć to na papierze?
Idąc dalej:
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.
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.