<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Alright. I prepared the data, sent it already to
ssterling-was-taken for review, but also i'll send it to here [as
Step 5 suggests of the Importing Guideline]</p>
<p>I have created two files:</p>
<ol>
<li> <a moz-do-not-send="true"
href="https://github.com/attilakundev/osm-files/blob/main/WV%20existing%20state%20forests%20modification.osm">WV
existing state forests modification.osm</a></li>
<li> <a moz-do-not-send="true"
href="https://github.com/attilakundev/osm-files/blob/main/WV%20State%20Forest%20Import.osm">WV
State Forest Import.osm</a></li>
</ol>
<p>Note that in the following bullet list the forest / state forest
refers to <b>boundary </b>and <b>not </b><b>landcover</b>, i
strongly emphasize this:<br>
</p>
<ul>
<li>First of all, the first file is updating the existing state
forests, for reference, i left the multipolygon used by WV GIS
tech center, so you can check it out as a reference.</li>
<li>I also downloaded the nodes of the state forests (in both
files and those are GNIS imports) because I don't know if I can
delete it, because i don't feel to leave them there, especially
if we have the forest boundary ways or relations.</li>
<li>The second file contains the unimported state forests (they
only exist as a node in OSM).</li>
<li>For Coopers Rock State Forest I left the already mapped way
and put it into the rest of the WV GIS Tech Center's data, but
the data from WVGISTC seems to be more accurate (not just hand
drawn from USGS topo map), though i deleted it from the file,
but if you feel the need to replace it to the more accurate way
rather leaving the hand drawn way, tell me, and then I'll do a
replace geometry on it (actually utils2plugin supports this in
JOSM, it's pretty simple, it conserves the original way's
history on a random node of the replaced way)</li>
<li>What i wrote here should also apply to: Camp Creek S.F. and
Calvin Price S.F.</li>
<li><a
href="http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/wvStateForestBoundaries_wvdof_20200916_utm83_shp.zip">http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/wvStateForestBoundaries_wvdof_20200916_utm83_shp.zip</a>
here is the shape file from the page i supplied in the source
section, if you want to have a look in it, just use opendata
plugin in JOSM and load the zip file in it. For some reason if
you try to upload the data even if you edited it, JOSM has the
switch upload=false for some reason... But you can turn it that
to upload=true via clicking the layer and select discourage
uploading which turns upload to true. (but of course you're not
gonna upload this, because you all are not the importers but me,
this was just a side note)</li>
<li>for understanding the tagging of the nodes, check out the PAD
US manual here, because that's how i understood how to tag the
multipolygons: <a
href="http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/PADUS_Schema.pdf">http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/PADUS_Schema.pdf</a></li>
<li>For source= tags for each boundaries/relations, in the
existing forests i put USGS or USGS topo maps on it, because
that's what the changeset of the previous mappers told on it,
but for all of the forests I did the WV GIS Technical Center; WV
Division of Forestry[;WV Division of Natural Resources] , where
[] is optional, if there is a GIS_SRC field. WV GIS Technical
Center is the aggregator, the original source is WV Division of
Forestry (or WVDoF in short). As mentioned, all data they
collect are Public Domain, unless stated explicitly like in the
case of their dataset #<a moz-do-not-send="true"
href="https://wvgis.wvu.edu/data/dataset.php?ID=442">442</a>(imagery
of the 55 counties).<br>
</li>
<li>For changesets, Clifford Snow suggested that to link the
import page, however, i have mixed feelings, and rather have the
link to the dataset's page what i set up originally (<a
class="moz-txt-link-freetext"
href="https://wvgis.wvu.edu/data/dataset.php?ID=58">https://wvgis.wvu.edu/data/dataset.php?ID=58</a>)
and probably would add "discussed on imports mailing list"</li>
</ul>
<p> If you all got any questions, remarks of what to change, please
tell me. I tried to give in all my knowledge. Of course, the
untagged nodes will be changed, and such just i left them for
reference.</p>
<p>P.S. i had to recopy this email because i wanted to send files
through mailing list but there is an upload limit, so i uploaded
to my github repo i just created (osm-files). I put the disclaimer
that nobody should upload the half-done data because then they're
going to cause unwanted consequences.. (like conflicts/duplicates
when i'm trying to upload) Instead i'm gonna do the job with your
help. I know i'm strict with the repo but i would've better just
sent it through email but there was this blockage:</p>
<pre class="c-mrkdwn__pre" data-stringify-type="pre" style="box-sizing: inherit; margin: 4px 0px; padding: 8px; --saf-0:rgba(var(--sk_foreground_low,29,28,29),0.13); font-size: 12px; line-height: 1.50001; font-variant-ligatures: none; white-space: pre-wrap; overflow-wrap: break-word; word-break: normal; tab-size: 4; font-family: Monaco, Menlo, Consolas, "Courier New", monospace !important; border: 1px solid var(--saf-0); border-radius: 4px; background: rgba(var(--sk_foreground_min,29,28,29),0.04); counter-reset: list-0 0 list-1 0 list-2 0 list-3 0 list-4 0 list-5 0 list-6 0 list-7 0 list-8 0 list-9 0; color: rgb(209, 210, 211); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Your mail to 'Imports' with the subject
Re: [Imports] Fwd: Importing West Virginia State Forests Boundary
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 386579 bytes with a limit of 40 KB</pre>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/12/2021 8:14 PM, stevea wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1A038FFC-FD40-4421-9CA5-30F50BA7E6E0@softworkers.com">
<pre class="moz-quote-pre" wrap="">This from someone who has struggled with (for at least 12 years) and perhaps enjoyed some success with many quite difficult topics related to a complex, county-wide landuse import [1] that I did not initiate (which remains in OSM after nine, ten additional data updates / iterations and seems to be responsible for winning an OSM Gold Star award from bestofosm.org with the comment "nearly perfect landuse"): the sort of landuse import you propose / do CAN be done, and done well. Moreover, it can be done with seemingly-conflicting (but not, actually) landCOVER (multi)polygons simultaneously with landUSE (multi)polygons. Both are not required (one or the other are "good additions to the map"), but both can co-exist if "done well."
Yes, all of that is a mouthful, but in my county, it has been a work-in-progress for over a decade. And yes, I know that some people dislike the results, but there isn't anything wrong or "non-OSM" about these data. Finally, they continue to get better, as the "teasing apart" of any "double-tagged" (both landuse and landcover on the same polygon) is well underway and DOES improve the data over time.
There are an infinity of both correct and incorrect methods to import or curate data into OSM. Please, continue to both dialog with the community in a forum such as this, as well as looking at data examples which are actually in our map. There is more than one way to get reasonable, smartly imported data into OSM, and especially with imports, it includes community consensus that what you are doing and how you are doing it is "correct" in some sense. Yes, it might be "only somewhat correct" as of the day of import (for example, the infamous TIGER import in the USA), with some correction required as both tastes and tagging standards / expectations / semantic flavors evolve over time (and they DO). But please strive to make any import as "correct as possible given what we know and have standardized today" and you should be in good shape to receive the sort of community peer-review that it takes to generate consensus.
There are not always easy, clear answers here, as the complexities of the data often yield many subtle decision forks being required on a path towards community acceptance.
SteveA
[1] <a class="moz-txt-link-freetext" href="https://wiki.osm.org/Santa_Cruz_County,_California#Landuse">https://wiki.osm.org/Santa_Cruz_County,_California#Landuse</a>
_______________________________________________
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>