[Imports] Fwd: Importing West Virginia State Forests Boundary

[Attila Kun]

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
>