[Imports] Fwd: Importing West Virginia State Forests Boundary

[Attila Kun]

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]

I have created two files:

 1. WV existing state forests modification.osm
    <https://github.com/attilakundev/osm-files/blob/main/WV%20existing%20state%20forests%20modification.osm>
 2. WV State Forest Import.osm
    <https://github.com/attilakundev/osm-files/blob/main/WV%20State%20Forest%20Import.osm>

Note that in the following bullet list the forest / state forest refers 
to *boundary *and *not **landcover*, i strongly emphasize this:

  * 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.
  * 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.
  * The second file contains the unimported state forests (they only
    exist as a node in OSM).
  * 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)
  * What i wrote here should also apply to: Camp Creek S.F. and Calvin
    Price S.F.
  * 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>
    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)
  * 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:
    http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/PADUS_Schema.pdf
    <http://data.wvgis.wvu.edu/pub/Clearinghouse/Boundaries/stateForestBoundaries/PADUS_Schema.pdf>
  * 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 #442
    <https://wvgis.wvu.edu/data/dataset.php?ID=442>(imagery of the 55
    counties).
  * 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
    (https://wvgis.wvu.edu/data/dataset.php?ID=58) and probably would
    add "discussed on imports mailing list"

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.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:

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


On 8/12/2021 8:14 PM, stevea wrote:
> 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] https://wiki.osm.org/Santa_Cruz_County,_California#Landuse
> _______________________________________________
> 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/20210812/939d9e6f/attachment-0001.htm>