<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>I get told from Sterling(as he's from WV), that the State Parks
are usually a bit off.<br>
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.<br>
<br>
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.</p>
<div class="moz-cite-prefix">On 8/13/2021 2:29 PM, Attila Kun wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6658feaf-4d5e-03bb-2476-535e98287ecd@attilakundev.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Usually relations have the source= tagging in the US, for
example <a class="moz-txt-link-freetext"
href="https://www.openstreetmap.org/relation/1476794"
moz-do-not-send="true">https://www.openstreetmap.org/relation/1476794</a>,
so we know where that exact data came from. It's also an import
as I see.<br>
<br>
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?"<br>
<br>
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.<br>
Alright, the thing is that the parcel viewer seems to be very
accurate and the State Forest avoids the properties and is
aligned properly.<br>
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: <a
class="moz-txt-link-freetext"
href="https://www.wvgis.wvu.edu/data/dataset.php?ID=371"
moz-do-not-send="true">https://www.wvgis.wvu.edu/data/dataset.php?ID=371</a></p>
<p>and the specific boundaries by the parcel map is here: <a
class="moz-txt-link-freetext"
href="https://mapwv.gov/parcel/?pid=50-08-0025-0001-0000"
moz-do-not-send="true">https://mapwv.gov/parcel/?pid=50-08-0025-0001-0000</a></p>
<p>So based upon this, this should be corrected and then reviewed,
that's my opinion about it.<br>
</p>
<div class="moz-cite-prefix">On 8/13/2021 2:16 PM, Mateusz
Konieczny via Imports wrote:<br>
</div>
<blockquote type="cite" cite="mid:MgzRB5b--3-2@tutanota.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div><a href="https://www.openstreetmap.org/relation/13085428"
rel="noopener noreferrer" target="_blank"
moz-do-not-send="true">https://www.openstreetmap.org/relation/13085428</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">is owner tag really correct? Are they owning all
area inside, including road parcels?<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">source tag in my opinion should be on changeset
only, but if local community disagrees<br>
</div>
<div dir="auto">feel free to ignore me<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a
href="https://www.openstreetmap.org/relation/13085428#map=19/37.97114/-82.32515"
moz-do-not-send="true">https://www.openstreetmap.org/relation/13085428#map=19/37.97114/-82.32515</a>
<br>
</div>
<div dir="auto">is it an actual geometry? (I know that USA
protected areas often have weird shapes, but...)<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Aug 13, 2021, 12:58 by <a class="moz-txt-link-abbreviated"
href="mailto:attila@attilakundev.com" moz-do-not-send="true">attila@attilakundev.com</a>:<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<p><br>
</p>
<div><a target="_blank" rel="noopener noreferrer" class=""
href="https://www.openstreetmap.org/changeset/109622189"
moz-do-not-send="true">https://www.openstreetmap.org/changeset/109622189</a>
This is the pilot import, that's where you can tell me what
to correct etc.<br>
</div>
<div> <br>
</div>
<div> 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.<span style="color: rgb(220, 221, 222); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: break-spaces; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgba(4, 4, 5, 0.07); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;"><span style="font-size:16px" class=""></span></span><br>
</div>
<p><br>
</p>
<div class="">On 8/13/2021 12:20 PM, Attila Kun wrote:<br>
</div>
<blockquote type="cite">
<div>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. <br>
</div>
<div> <br>
</div>
<div> On 8/13/2021 12:08 PM, Attila Kun wrote: <br>
</div>
<div> <br>
</div>
<blockquote type="cite">
<div>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. <br>
</div>
<div> <br>
</div>
<div> 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. <br>
</div>
<div> <br>
</div>
<div> 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). <br>
</div>
<div> <br>
</div>
<div> 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. <br>
</div>
<div> <br>
</div>
<div> 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. <br>
</div>
<div> <br>
</div>
<div> 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. <br>
</div>
<div> <br>
</div>
<div> On 8/13/2021 10:00 AM, Frederik Ramm wrote: <br>
</div>
<div> <br>
</div>
<blockquote type="cite">
<div>Minh, <br>
</div>
<div> <br>
</div>
<div> On 12.08.21 21:27, Minh Nguyen wrote: <br>
</div>
<div> <br>
</div>
<blockquote type="cite">
<div>The next time someone proposes a building import,
I'll be bracing myself <br>
</div>
<div> for a debate about the lack of associatedStreet
relations in an <br>
</div>
<div> unrelated address import. 🙈 <br>
</div>
</blockquote>
<div>I don't think you should make fun of my criticism.
The two imports are<br>
</div>
<div> not "unrelated", as they are being executed by the
same person within a <br>
</div>
<div> timeframe of less than a year. <br>
</div>
<div> <br>
</div>
<div> The person has not even seen fit to participate in
the discussion, <br>
</div>
<div> instead letting others do "the paperwork" for him,
which to me signifies <br>
</div>
<div> a certain unwillingness to take responsibility for
their actions. <br>
</div>
<div> <br>
</div>
<div> Are those the qualities you are looking for in
someone who imports data <br>
</div>
<div> in the US? <br>
</div>
<div> <br>
</div>
<div> The lack of relation use in that previous import
might well be a sign of <br>
</div>
<div> the importer being uncomfortable with relations
overall. In a boundary <br>
</div>
<div> import, the least you are looking for is that if a
protected area <br>
</div>
<div> boundary coincides with an adminisitrative
boundary, this is properly <br>
</div>
<div> recorded in OSM, rather than mindlessly throwing
in more and more <br>
</div>
<div> overlapping line geometries. <br>
</div>
<div> <br>
</div>
<div> Here's an example where this has been done well: <br>
</div>
<div> <br>
</div>
<div> <a target="_blank" rel="noopener noreferrer"
class=""
href="https://www.openstreetmap.org/relation/5880036"
moz-do-not-send="true">https://www.openstreetmap.org/relation/5880036</a>
"Scotts Basin Wilderness <br>
</div>
<div> Study Area", which happens to coincide with the
boundary of Juab county <br>
</div>
<div> for a bit, and as a result they both share <br>
</div>
<div> <a target="_blank" rel="noopener noreferrer"
class=""
href="https://www.openstreetmap.org/way/392275476"
moz-do-not-send="true">https://www.openstreetmap.org/way/392275476</a>.
<br>
</div>
<div> <br>
</div>
<div> Here on the other hand is an almost certainly bad
import: <br>
</div>
<div> <br>
</div>
<div> <a target="_blank" rel="noopener noreferrer"
class=""
href="https://www.openstreetmap.org/#map=16/35.1685/-109.6939"
moz-do-not-send="true">https://www.openstreetmap.org/#map=16/35.1685/-109.6939</a>
<br>
</div>
<div> <br>
</div>
<div> because whoever has imported the boundary of
"Petrified Forest National <br>
</div>
<div> Park" or the "Navajo Nation" (I haven't checked
which came first) has <br>
</div>
<div> allowed both to overlap, leading OSM to mistakenly
claim that a part of <br>
</div>
<div> the National Park lies inside the Aboriginal
Lands. I don't doubt that <br>
</div>
<div> both data sets came from some official source but
in my opinion it is <br>
</div>
<div> the duty of the importer, as part of proper
conflation work, to fix such <br>
</div>
<div> problems (which may occasionally even mean: do
some research!) rather <br>
</div>
<div> than just dumping it into OSM for someone else to
care. <br>
</div>
<div> <br>
</div>
<div> My mantra regarding imports is, if you don't have
the time to do it <br>
</div>
<div> right, let's wait for a volunteer who has that
time, rather than rushing <br>
</div>
<div> an import just do bring more coloured specks onto
the map. <br>
</div>
<div> <br>
</div>
<div> Bye <br>
</div>
<div> Frederik <br>
</div>
<div> <br>
</div>
</blockquote>
</blockquote>
<div><br>
</div>
<div>_______________________________________________<br>
</div>
<div> Imports mailing list <br>
</div>
<div> <a target="_blank" rel="noopener noreferrer" class=""
href="mailto:Imports@openstreetmap.org"
moz-do-not-send="true">Imports@openstreetmap.org</a> <br>
</div>
<div> <a target="_blank" rel="noopener noreferrer" class=""
href="https://lists.openstreetmap.org/listinfo/imports"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/imports</a>
<br>
</div>
</blockquote>
</blockquote>
<div dir="auto"><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Imports mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Imports@openstreetmap.org" moz-do-not-send="true">Imports@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/imports" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/imports</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Imports mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/imports">https://lists.openstreetmap.org/listinfo/imports</a>
</pre>
</blockquote>
</body>
</html>