<div dir="ltr">I like to point the changeset source to the wiki import page. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 12, 2021 at 8:59 AM Attila Kun <<a href="mailto:attila@attilakundev.com">attila@attilakundev.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Also i got the question in mind, what should be the source
      tagging?</p>
    <p>I set up a long tagging for the exact source for the changesets(<font face="monospace">source="<a rel="nofollow" href="https://wvgis.wvu.edu/data/dataset.php?ID=58" target="_blank">https://wvgis.wvu.edu/data/dataset.php?ID=58</a>
        discussed with #local-west-virginia on OSM US Slack and imports
        mailing list"
      </font>), but shouldn't I just  write<font face="monospace">
        source=WV GIS Tech Center; WVDoF</font> instead of it?</p>
    <p>Because that would make everything easier, and it's gonna be
      documented on wiki nevertheless...<br>
    </p>
    <div>On 8/12/2021 5:26 PM, Attila Kun wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p>Yes, you didn't misread it, it's about a Boundary import aka
        boundary=protected_area.<br>
      </p>
      <p>As it reads in the dataset description, "Last Revised in 2020
        for USGS's Protected Areas Database, a subset of the National
        Gap Analysis project." So it means I'm gonna work with pretty
        decent data which is a good thing, and i checked the quality of
        the dataset, I only need to do some minor multipolygon editing,
        i already set up the tagging, so yeah, i'm not gonna import it
        like an idiot but like i have proper knowledge how to, after
        some research of how the taggings work. The taggings of the
        dataset is based on the PAD US scheme, for which WV GIS TC
        provided a PDF file to explain what tag does what.</p>
      <p>I haven't started it yet, but i guess you all say that i should
        be good to go if I do it carefully, but that's why I wanted to
        hear from you.</p>
      <p>I created a <a href="https://www.openstreetmap.org/user/ottwiz_import" target="_blank">separate
          account </a>just for the import itself so it's distinguished
        from my main one.<br>
      </p>
      <div>On 8/12/2021 4:52 PM, Adam Franco
        wrote:<br>
      </div>
      <blockquote type="cite">
        
        <div dir="ltr">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > On 12 Aug 2021,
              at 08:38, Mateusz Konieczny via Imports <<a href="mailto:imports@openstreetmap.org" target="_blank">imports@openstreetmap.org</a>>
              wrote:<br>
              I disagree. For simple polygons (few nodes), overlapping
              ways might be the easiest to maintain representation, but
              as an editor I would always prefer a multipolygon to tens
              or hundreds of reused/overlapping nodes in overlapping
              ways.<br>
            </blockquote>
            <div>As a heavy land-cover mapper I agree that multipolygons
              are vastly easier to improve over time than to try to
              disconnect overlapping ways.</div>
            <div><br>
            </div>
            <div>That said, unless I'm misreading the wiki the i<a href="https://wiki.openstreetmap.org/wiki/Import/West_Virginia_State_Forests_Import" target="_blank">mport being discussed</a> is
              about State Forest (protected area) boundaries not
              land-cover/land-use. I'd rather not have folks doing
              land-cover/land-use imports from poor data, but I'm of the
              opinion that protected area boundaries are often a very
              good candidate for [careful] importing if the data are of
              good quality.<br>
            </div>
          </div>
        </div>
        <br>
        <fieldset></fieldset>
        <pre>_______________________________________________
Imports mailing list
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a>
</pre>
      </blockquote>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Imports mailing list
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>@osm_washington<br></div><div><a href="https://www.snowandsnow.us" target="_blank">www.snowandsnow.us</a></div><div>OpenStreetMap: Maps with a human touch</div></div></div></div></div></div></div>