<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I have for example ssterling-was-taken, a local West Virginian,
      who may help me monitor the process(I talk with him on a daily
      basis), or wolfgang8741 who has also a great knowledge of WV and
      lived in it. (and there are some others as well)</p>
    <p>For the existing forest boundaries, i'm planning to keep them,
      but there is a State Forest boundary, which is partly done, I'm
      talking about <a
        href="https://www.openstreetmap.org/way/852541565">Coopers Rock
        State Forest </a>in Monongalia and Preston Counties, luckily
      all of the state forests don't overlap or anything, so adding ways
      into an existing multipolygon seems an easy thing.</p>
    <p>I have pretty good knowledge of how multipolygons work after many
      trial and error.<br>
    </p>
    <p>Attila</p>
    <p>P.S. if you say i can start doing my import, then i'll start,
      i'll be careful what i do, and thorough, since there are ways that
      are not in a multipolygon and it belongs to the same thing, in
      this case, State Forest.<br>
    </p>
    <div class="moz-cite-prefix">On 8/11/2021 11:18 PM, Minh Nguyen
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:sf1eqg$2s1$1@ciao.gmane.io">Vào
      lúc 13:15 2021-08-11, Frederik Ramm đã viết: <br>
      <blockquote type="cite">* There's a bunch of bubbly residential
        areas that nobody tracing from aerial imagery would classify as
        such. For example, why is
        <a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/way/863679643">https://www.openstreetmap.org/way/863679643</a> shaped the way it is
        and why does it have this little hole in the South? If that is
        the "official" data then maybe OSM is better off without it.
        <br>
      </blockquote>
      <br>
      To me, the specific characteristics of the imported landuse data
      in Rhode Island are somewhat off-topic, since the proposal is to
      import a different kind of data in a very different geography. But
      for what it's worth, that little hole is apparently a pond.
      Reasonable people have disagreed over whether to exclude a pond
      from landuse areas when it sits at the edge between the two areas.
      I suppose the argument is that a manual mapper would've added the
      pond, but don't say that too loudly or someone will suggest a
      water import. ;-) <br>
      <br>
      <blockquote type="cite">* Why do neighbouring large landuse
        polygons duplicate tens of thousands of nodes instead of being
        modelled as relations both sharing one way?
        <br>
      </blockquote>
      <br>
      If Brian had done that where I map, I would've pleaded for the
      import to be reworked or reverted. Ways sharing nodes, sure, but
      modeling landuse areas as relations just because they border each
      other would be incredibly unfriendly to any mapper who has to
      maintain the data as landuse changes in the future. Even then,
      there's debate over whether landcover like woods should even be
      connected to landuse=residential, due to things like wooded lots,
      which are very common where I map and across much of West
      Virginia. <br>
      <br>
      I suspect your point about conlation would become more relevant if
      there's any interest in importing an actual landuse dataset, given
      Attila's prolific hand-drawing of landuse areas in West Virginia
      over the past year. But anyways, back to boundaries... <br>
      <br>
      <blockquote type="cite">(For example, since it appears that the
        plan is to import boundaries here, I would be interested to
        learn of any conflation plans with existing administrative
        boundaries if/where state forests should coincide with them?)
        <br>
      </blockquote>
      <br>
      Do you mean that the protected area relations should reuse the
      ways that are members of the administrative boundary relations, or
      that they should consist of new ways that share nodes with the
      existing ways? Either form of conflation would be a rather
      aggressive step that I would caution against even with manual
      mapping. Better to keep the boundaries separate unless you know
      otherwise. <br>
      <br>
      In the U.S., state park boundaries correspond to property lines
      but, like property lines, often don't neatly correspond to
      municipal or county administrative boundaries. I'd imagine this to
      be especially true in states that were surveyed with metes and
      bounds, like Rhode Island and West Virginia. By contrast,
      boundaries are a bit neater under the Public Land Survey System,
      which is why you often see a checkerboard pattern in parklands out
      west. But just the other day I mapped an incorporated town in
      Indiana (PLSS) that sits inside a state park inside another state
      park, so the boundary situation is far from rational no matter the
      survey method. <br>
      <br>
      The other mitigating factor is that West Virginia is one of the
      less densely populated states, so I'd assume most state forest
      boundaries would be somewhat far away from any municipal boundary.
      <br>
      <br>
      I do agree that local residents should help to monitor this
      import, just in case there are any blind spots. Luckily, there are
      a couple West Virginians on OSMUS Slack, so I'd encourage keeping
      them in the loop, if for no other reason than they'll be partly
      responsible for maintaining this data going forward. <br>
      <br>
    </blockquote>
  </body>
</html>