<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/changeset/109622189">https://www.openstreetmap.org/changeset/109622189</a> This is the
pilot import, that's where you can tell me what to correct etc.<br>
<br>
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-size: 16px; 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></p>
<div class="moz-cite-prefix">On 8/13/2021 12:20 PM, Attila Kun
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:331b3b70-ef12-6b99-de34-9da5456a7253@attilakundev.com">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>
<br>
On 8/13/2021 12:08 PM, Attila Kun wrote:
<br>
<blockquote type="cite">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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
On 8/13/2021 10:00 AM, Frederik Ramm wrote:
<br>
<blockquote type="cite">Minh,
<br>
<br>
On 12.08.21 21:27, Minh Nguyen wrote:
<br>
<blockquote type="cite">The next time someone proposes a
building import, I'll be bracing myself
<br>
for a debate about the lack of associatedStreet relations in
an
<br>
unrelated address import. 🙈
<br>
</blockquote>
I don't think you should make fun of my criticism. The two
imports are
<br>
not "unrelated", as they are being executed by the same person
within a
<br>
timeframe of less than a year.
<br>
<br>
The person has not even seen fit to participate in the
discussion,
<br>
instead letting others do "the paperwork" for him, which to me
signifies
<br>
a certain unwillingness to take responsibility for their
actions.
<br>
<br>
Are those the qualities you are looking for in someone who
imports data
<br>
in the US?
<br>
<br>
The lack of relation use in that previous import might well be
a sign of
<br>
the importer being uncomfortable with relations overall. In a
boundary
<br>
import, the least you are looking for is that if a protected
area
<br>
boundary coincides with an adminisitrative boundary, this is
properly
<br>
recorded in OSM, rather than mindlessly throwing in more and
more
<br>
overlapping line geometries.
<br>
<br>
Here's an example where this has been done well:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/relation/5880036">https://www.openstreetmap.org/relation/5880036</a> "Scotts Basin
Wilderness
<br>
Study Area", which happens to coincide with the boundary of
Juab county
<br>
for a bit, and as a result they both share
<br>
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/way/392275476">https://www.openstreetmap.org/way/392275476</a>.
<br>
<br>
Here on the other hand is an almost certainly bad import:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/#map=16/35.1685/-109.6939">https://www.openstreetmap.org/#map=16/35.1685/-109.6939</a>
<br>
<br>
because whoever has imported the boundary of "Petrified Forest
National
<br>
Park" or the "Navajo Nation" (I haven't checked which came
first) has
<br>
allowed both to overlap, leading OSM to mistakenly claim that
a part of
<br>
the National Park lies inside the Aboriginal Lands. I don't
doubt that
<br>
both data sets came from some official source but in my
opinion it is
<br>
the duty of the importer, as part of proper conflation work,
to fix such
<br>
problems (which may occasionally even mean: do some research!)
rather
<br>
than just dumping it into OSM for someone else to care.
<br>
<br>
My mantra regarding imports is, if you don't have the time to
do it
<br>
right, let's wait for a volunteer who has that time, rather
than rushing
<br>
an import just do bring more coloured specks onto the map.
<br>
<br>
Bye
<br>
Frederik
<br>
<br>
</blockquote>
</blockquote>
<br>
_______________________________________________
<br>
Imports mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/imports">https://lists.openstreetmap.org/listinfo/imports</a>
<br>
</blockquote>
</body>
</html>