[Imports] Fwd: Importing West Virginia State Forests Boundary

[Attila Kun]

https://www.openstreetmap.org/changeset/109622189 This is the pilot 
import, that's where you can tell me what to correct etc.

Alright, since this is a state forest, i think this should be tagged 
with a protect_class tag, but the original tags of the relation has 
nothing on the IUCN Classification. Brian told me that such things are 
class 5 or 6, but there is no such a thing. According to PAD US it's 
"Other Conservation Area" for IUCN Category, meanwhile there is no such 
a class assigned in IUCN, so if you could help in this case, i'd 
appreciate it. Thank you all for your help in advance.

On 8/13/2021 12:20 PM, Attila Kun wrote:
> P.S. After consulting with Friendly_Ghost / Casper, I'll put the GNIS 
> feature ID on the relations / ways, because sometimes it's useful to 
> check data from GNIS website. But yeah, if the import needs to be 
> improved, or reverted because it doesn't meet the level of OSM, leave 
> me a comment on the changeset, which i'll provide soon.
>
> On 8/13/2021 12:08 PM, Attila Kun wrote:
>> By the way, I was the initiator to make this import real, just i was 
>> like "I want someone else to do the import rather me doing, because i 
>> didn't do such a boundary import", but after you said this should be 
>> rethought, i'm going to grab the opportunity, and do a pilot import 
>> as Friendly_Ghost suggested on OSM World Discord this means, only one 
>> state forest which is a multipolygon.
>>
>> Also I'm going to be careful, since i saw some data mess in it, 
>> especially at Coopers Rock S.F. and Cabwaylingo S.F.
>>
>> I mean by mess, that there are some ways which belongs to the same 
>> State Forest  as the main relation but they're not members it and the 
>> data on them is just a redundancy i should say. So i just delete the 
>> data from them and then add them to the main relation as an outer 
>> member (because it's not in the big relation but rather a smaller 
>> member outside of it).
>>
>> To be honest. I started discussing it first on OSM US Slack, because 
>> that's where i initiate my thoughts and many people like Kevin Kenny, 
>> Minh, Brian added some comments on it (and Sterling, the local West 
>> Virginian was astonished that i'm doing this improvement"), what 
>> should i do, but no one had any objections. If any of the OSM US 
>> Slack members say "this is not alright", then i wouldn't have started 
>> it.
>>
>> I always ask first before do anything, which has been always a good 
>> trait of me, however we have to follow the OSM's guidelines on import 
>> that means everything is okay, and I always like to explain why data 
>> should be imported, especially when we got permissions to use them.
>>
>> Although if i don't do anything, then it won't be completed, so i'll 
>> start importing Cabwaylingo State Forest first, and then post here 
>> the results, and if you say, the data quality of it is okay, i'll 
>> continue with the rest. Also, I'm going to say, I'm going to delete 
>> the GNIS imported nodes, because those are unnecessary, especially 
>> the fact that the relations have more precise data and not like a 
>> data spam of when it was created like the gnis: tags.
>>
>> On 8/13/2021 10:00 AM, Frederik Ramm wrote:
>>> Minh,
>>>
>>> On 12.08.21 21:27, Minh Nguyen wrote:
>>>> The next time someone proposes a building import, I'll be bracing 
>>>> myself
>>>> for a debate about the lack of associatedStreet relations in an
>>>> unrelated address import. 🙈
>>> I don't think you should make fun of my criticism. The two imports are
>>> not "unrelated", as they are being executed by the same person within a
>>> timeframe of less than a year.
>>>
>>> The person has not even seen fit to participate in the discussion,
>>> instead letting others do "the paperwork" for him, which to me 
>>> signifies
>>> a certain unwillingness to take responsibility for their actions.
>>>
>>> Are those the qualities you are looking for in someone who imports data
>>> in the US?
>>>
>>> The lack of relation use in that previous import might well be a 
>>> sign of
>>> the importer being uncomfortable with relations overall. In a boundary
>>> import, the least you are looking for is that if a protected area
>>> boundary coincides with an adminisitrative boundary, this is properly
>>> recorded in OSM, rather than mindlessly throwing in more and more
>>> overlapping line geometries.
>>>
>>> Here's an example where this has been done well:
>>>
>>> https://www.openstreetmap.org/relation/5880036 "Scotts Basin Wilderness
>>> Study Area", which happens to coincide with the boundary of Juab county
>>> for a bit, and as a result they both share
>>> https://www.openstreetmap.org/way/392275476.
>>>
>>> Here on the other hand is an almost certainly bad import:
>>>
>>> https://www.openstreetmap.org/#map=16/35.1685/-109.6939
>>>
>>> because whoever has imported the boundary of "Petrified Forest National
>>> Park" or the "Navajo Nation" (I haven't checked which came first) has
>>> allowed both to overlap, leading OSM to mistakenly claim that a part of
>>> the National Park lies inside the Aboriginal Lands. I don't doubt that
>>> both data sets came from some official source but in my opinion it is
>>> the duty of the importer, as part of proper conflation work, to fix 
>>> such
>>> problems (which may occasionally even mean: do some research!) rather
>>> than just dumping it into OSM for someone else to care.
>>>
>>> My mantra regarding imports is, if you don't have the time to do it
>>> right, let's wait for a volunteer who has that time, rather than 
>>> rushing
>>> an import just do bring more coloured specks onto the map.
>>>
>>> Bye
>>> Frederik
>>>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210813/1d9398c4/attachment-0001.htm>