User @Yog_Sot has imported trees in Poznan, e.g. in Changeset: 177241335 | OpenStreetMap Changeset: 177356614 | OpenStreetMap Changeset: 177277531 | OpenStreetMap and it is obvious from errors like Node: 13457106214 | OpenStreetMap (a tree in the middle of tram tracks) that this import was not properly reviewed. Is anyone aware of a proper import process having been followed for these imports? If not I would suggest that I revert these edits. What do people think?
2 Likes
It’s not only in Poznań. Two months ago I noticed a lot of trees named “Dęby nad Skawinką”
https://www.openstreetmap.org/node/13566924888/history
And informed the author, and forgot about it
https://www.openstreetmap.org/changeset/178588127#map=10/49.9916/19.9720
I can see that the only change was plural “Dęby” to singual “Dąb” but it’s still likely incorrect.
I don’t recall that an import in particular concerning the above mentioned changesets has been discussed anywhere on the PL-forum.
It may have do something with this thread, but I don’t find there any information about the mentioned changesets either.
I asked some questions and got some replies in this thread: Adding the type of tree (species, genus) - #8 by ivanbranco
@woodpeck
i live in the city and i did confirm those trees by survey, street level photos or aerial maps from different years to confirm location and adjust it, made sure that duplicates are not there. It was discussed over polish discord as well.
If you’re finding some trees with unprecise location, those can be fixed by adjusting it. “empty” values do happen as i could have missed those as well, but those can be fixed.
It’s not just an import but lots of surveys as well.
If you’re finding a tree that location is inaccurate, feel free to correct it. I might have seen the tree, but have unprecise coordinates for it, moved it the wrong direction while mapping and even tho tripple checking if the tree is there on aerial map, could have missed it.
So that one tree you have found in the middle of the street have been missed.
There were 2 other trees deleted a month ago or so. That makes just 3 trees that were added with improper location.
@Yunkers simply check official sources
It’s quite logical that every single of those monumental trees can be called by its singular form
This kind of protection for has no area to give a name, yet the name is official and should be given.
But yeah, go ahead, propose something, be constructive
As @szydzio mentioned, this is nothing new, but as for the data collection, i still have got the genus issue to correct that @ivanbranco has successfully identified and fixed.
I still have got too little time to do the neccessary properly these days, but will do.
It has to be done carefully tho, because it’s easy for a few errors, that can get mapped to OSM, and then people get very much confused, that errors do happen and sometimes they propose to delete the whole thing instead fixing the few errors.
1 Like
Już ci proponowałem relacje grupująca dla takich przypadków. Pomnikiem przyrody jest grupa drzew i to grupa drzew ma nazwę. Zduplikowana nazwa dla każdego drzewa z osobna jest niepoprawna i mega nieczytelna.
To co zrobiłeś trochę przypomina jakbyś dał nazwę “Las Wolski” dla każdego drzewa, zamiast dla lasu.
3 Likes
takich relacji grupujących są rozmaite typy i żadna nie jest powszechnie rozpoznawana.
Łatwo dojść natomiast do wniosku iż pojedyncze drzewo z nazwej grupy może nosić nazwę w liczbie pojedynczej.
To iż indywidualne elementy wewnątrz większej nazwanej grupy otrzymują parametry tej grupy jest również powszechne. Kod inspire PL.ZIPOP.1393.PP.1206113.3132 czy identyfikator fop ref:CRFOP dotyczą całej grupy, ale nosi je każdy element z osobna aby były one wiadome.
Jest to bardzo porównywalne do tzw street relation iz mozna argumentować, iż to ta relacja powinna mieć nazwę ulicy, a nie wszystkie jej osobne człony jak chodniki czy jezdnie. Jednakże mimo, że chodniki równiez nosza nazwę ulicy, to nazywamy wyłącznie jezdnie, choć w Toronto nazywają równiez chodniki, bo im się nie spodobało iz nazywamy tylko jednie, ale street relacja też się nie przyjęła.
Naturalnie pomysł na szeroką dyskusje jest na miejscu i możesz się tez dowiedzieć co ludzi myslą o relacji dla drzew.
Dla zbiorowego pomnika preferuję relację. Zmiana nazwy w liczbie mnogiej na pojedynczą i przypisanie poszczególnym obiektom może prowadzić do wątpliwych językowo konsekwencji. Przykład z Lasem Wolskim jest dobry.
4 Likes
w przypadku łąki czy lasu, relacja multipolygon dla landuse jest dobrze ospecyfikowana i powszechnie stosowana, więc absolutnie nie ma potrzeby nazwać każdego kawałku landuse osobno.
W przypadku relacji grupującej punktowe twory sytuacja jest inna. A dodatkowo nie każda grupa nazwanych drzew ma nazwę z której pozpośrednio wynika nazwa dla każdego drzewa z osobna.
Osobiście bardzo mnie irytuje brak możliwości grupowania i mnogośc rozmaitych relacji do wyoboru i brak specfikacji choćby jakie role powinny przyjmowac pojadyncze drzewa, a jakie np rzędy drzew.
+1
O relacji pisałem już na etapie dyskusji o CRFOP, szkoda, że potem nie zostało to jednak uwzględnione.
może coś w rodzaju type=multiobject lub type=cluster?
No może, ale mija 7 lat i nitkt nie uznał tego za odpowiednia metodę i nikt tego nigdzie nie implementował i absolutnie nie mam pomysłu jak to zmienić.
Metodę tree_row też analizowałem, ale raz, żę taki obiekt nie zasługuje na nazwę najwyraźniej ;] A dwa większośc pomników składa się przynajmniej z dwóch rzędów, więc zgodnie z logiką, że nie nazywamy pojedynczych elementów, tree_row tez jest takim elementem, więc logicznie nie ma praktycznego uzasadnienia. I co poradzić
I opened a thread about the topic a couple years ago:
Eventually I documented type=site + natural=tree_group + denotation=natural_monument in the wiki page for italian monumental trees.
3 Likes
sometimes there are trees where actual area is specified, and right there it was mapped so
Supposedly 24 Pseudotsuga menziesii are protected there,
but only like half of em have measured coordinates xD So it’s the area that is protected, not just individual trees.
Tho such a protction type is actually very rare around here.
As for relaions, i have tried type=site here grouping tree rows (tho individual trees should likelly be added as well)
and another type=site where 3 trees and 2 rows form the natural monument, but since those 3 trees does, i have added all of em with member role and the rows got tree_row role
What roles do you specify, coz that wiki specs don’t seam to say (autotranslated it to english)
Cały czas rozważam tutaj przypadek grupy drzew, a nie obszaru. Co będzie, jak taki pomnik przyrody nazywa się Dęby w Pierdziszewie albo Pierdziszewska Olszyna?
Mnie też. Ale w takich przypadkach po prostu powstrzymuję się od mapowania.
W takich przypadkach trzeba po prostu mapować według specyfikacji (a tutaj jak widać coś już zostało opracowane) - jeśli komuś będzie zależało żeby daną informację pokazać to i tak musi wymyślić sposób żeby tego użyć.
Nie powstrzymywałbym się od mapowania tylko dlatego że czegoś nie widać na pierwszy rzut oka. Jeśli dana metoda jest wystarczająco popularna to i rendering się pojawia. Czasem wystarcza być cierpliwym lub po prostu zgłosić sprawę bezpośrednio do twórców.
Chyba najgorszym co można zrobić to wymyślić swoją własną regułę i spodziewać się że użytkownicy w jakiś sposób domyślą się o co chodziło. A to chyba niestety tutaj się stało.y
4 Likes
Tego typu edycja wymaga:
- podania źródła danych w zestawie zmian
- utworzenia strony na Wiki dotyczącej automatycznej edycji: https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
- spełnienia: https://wiki.openstreetmap.org/wiki/Import/Guidelines
Rozmowa na czacie to za mało.
This type of edit requires:
- specifying the data source in the changeset
- creating a Wiki page about automated edits: https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
- compliance with: https://wiki.openstreetmap.org/wiki/Import/Guidelines
A chat conversation is not enough.
źródła w zestawach to przeoczenia.
edycja nie jest automatyczna, to nie jest import. dane zostały przetworzone oraz ręcznie zmienione poprzez weryfikację duplikatów oraz pozostałych drzew - te dodane dane są odmienne od tej uzyskanej informacji poblicznej
rozmowa na czacie uzupełniona jest wątkiem, który został zalinkowany wyżej. Ponadto w kwestii dodawania pomników przyrody, one były dodawane właśnie w taki sposób, który został już wcześniej uzgodniony, więc nie robiłem nic specjalnie nowego.
Dlatego zachęcam cię do dodawania drzew, a zwłaszcza pomników przyrody z bazy gotowej do załadowania przez JOSM. Upewnij się natomiast by zweryfikować to co dodajesz zgodnie z załączoną instrukcją. Musisz również upewnić się, że gdy species ma tę samą wartość co genus, to species trzeba usunąć zgodnie z wątkiem, który przytoczył @ivanbranco
2 Likes
serio? Te 10 000 drzew w samym Changeset: 177241335 | OpenStreetMap nie są przerobionymi danymi z jakiegoś źródła?
Twierdzisz że wszystkie były zweryfikowane wizytą na miejscu lub chociaż sprawdzeniem na zdjęciach lotniczych?
1 Like
To że dane wymagały jakichś ręcznych poprawek nie oznacza że to nie jest import. Myślę że na osm nigdy nie odbył się (poprawny) import który nie wymagałby żadnych ręcznych przeróbek lub manipulacji danymi na jakimś etapie.
Nawet najprostszy import budynków czy adresów wymaga ręcznego sprawdzenia czy nie dodajesz chociażby wyburzonych budynków. Ale to wciąż import.
2 Likes
to,
spędziłem nad tym bardzo dużo czasu.
Było dla mnie szczególnie istotne, aby nie tworzyć duplikatów i przy okazji zauważyłem że inni przede mną również dodawali drzewa na podstawie tej dostępnej bazy zieleni, którą dodatkowo otrzymałem informacją z urzędu.
Na miejscu weryfikowałem aby sprawdzić jak bardzo można wierzyć opisom gatunków czy opisie iż drzewo przeznaczone jest do wycinki.
Ciekawostką jest iż niektóre pomniki przyrody mają opisany inny gatunek i parametry niż CRFOP i dostałem odpowiedz, że urząd miasta uważa, że w CRFOP jest błąd, ale jednocześnie nie potrafią o tym poinformować pomimo obowiązku jaki mają, więc wizytacją na miejscu starałem się sprawdzić czy CRFOP ma prawidłowe dane, czy też te od urzędu miasta są rzeczywiste.
Ale według tych danych też niby był jakiś urojony pomnik przyrody z lokalizacją cytuję: “przy żabce” więc no weryfikowałem takie kwiatki
Choć owszem były przeoczenia, całą dyskusję rozpoczęło info o jednym źle dodanym drzewie, które skasowałem i będę weryfikował każde takie zgłoszenie.
No tak, rysowanie budynków w iD na warstwie ewidencji budynków też spełnia w takim razie definicje importu.
Mi chodzi o to, że są importy, które ktoś robi na pałę, tak jak np wszystkie dodane pomniki przyrody w całym kujawsko pomorskim przez niejakiego Stefan Paluch, że po prostu dodał wszystko co było w CRFOP na tamten czas dla tego całego województwa… A można robić edycje na podstawie danych z każdorazową weryfikacją, tak jak robię to ja tak dobrze jak potrafię.