[Imports] Fwd: Importing West Virginia State Forests Boundary

Attila Kun attila at attilakundev.com
Fri Aug 13 12:58:34 UTC 2021 

Well, to be honest, I'm talking on Discord and Slack as well on the 
case, what I realize is that only survey can correct the boundaries, and 
not armchair mapping, so for now the time being, i decided to leave the 
boundaries as is, especially because it is made to USGS PAD US firstly.

I get told from Sterling(as he's from WV), that the State Parks are 
usually a bit off.
Actually my purpose is just to import the boundaries and check if there 
are inconsistency errors. So editing it by boundary would be the purpose 
of my main account.

Until we'll see the final solution for the geometry what would be the 
best, i'm not going to import more, but it seems that we don't have much 
choice, to check the borders to USGS Topo maps, and the area, or just 
leave it as-is.

On 8/13/2021 2:29 PM, Attila Kun wrote:
>
> Usually relations have the source= tagging in the US, for example 
> https://www.openstreetmap.org/relation/1476794, so we know where that 
> exact data came from. It's also an import as I see.
>
> But, i'm checking the boundaries to the imagery and to the WV parcel 
> map, also to the USGS topo maps, and the result is: "what?"
>
> USGS topo maps seem to be more accurate, but i really bet that the 
> properties aren't under the ownership of WV DoF. If that's the case, 
> i'll have to correct the boundaries.
> Alright, the thing is that the parcel viewer seems to be very accurate 
> and the State Forest avoids the properties and is aligned properly.
> Well, i don't know much we can use that data as reference (just for 
> viewing), but i'll leave you the link for it: 
> https://www.wvgis.wvu.edu/data/dataset.php?ID=371
>
> and the specific boundaries by the parcel map is here: 
> https://mapwv.gov/parcel/?pid=50-08-0025-0001-0000
>
> So based upon this, this should be corrected and then reviewed, that's 
> my opinion about it.
>
> On 8/13/2021 2:16 PM, Mateusz Konieczny via Imports wrote:
>> https://www.openstreetmap.org/relation/13085428 
>> <https://www.openstreetmap.org/relation/13085428>
>>
>> is owner tag really correct? Are they owning all area inside, 
>> including road parcels?
>>
>> source tag in my opinion should be on changeset only, but if local 
>> community disagrees
>> feel free to ignore me
>>
>> https://www.openstreetmap.org/relation/13085428#map=19/37.97114/-82.32515 
>> <https://www.openstreetmap.org/relation/13085428#map=19/37.97114/-82.32515> 
>>
>> is it an actual geometry? (I know that USA protected areas often have 
>> weird shapes, but...)
>>
>>
>> Aug 13, 2021, 12:58 by attila at attilakundev.com:
>>
>>
>>     https://www.openstreetmap.org/changeset/109622189
>>     <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
>>>>>     <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
>>>>>     <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
>>>>>     <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 <mailto:Imports at openstreetmap.org>
>>>     https://lists.openstreetmap.org/listinfo/imports
>>>     <https://lists.openstreetmap.org/listinfo/imports>
>>
>>
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>
> _______________________________________________
> 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/03a25402/attachment-0001.htm>

More information about the Imports mailing list