[Imports] National Park Boundaries in Hawaii

[Kevin]

The USGS Gap Analysis Program (GAP) (http://gapanalysis.nbii.gov) has 
some of the best datasets available for parks that play some part in 
conservation, ball fields and the like usually won't be included in the 
datasets.  A GAP analysis has been completed for all states and several 
regional updates have also been completed.  As part of this project a 
stewardship or conservation lands database would have been created.  
These lands will include federal (including military bases), state, 
local, and private lands that have some sort of designated conservation 
status and typically utilize the best datasets available at the time.  
Most states were completed in the 2000's, so they should be pretty 
current.  you'd be surprised how often boundaries for these lands 
change.  Hawaii's stewardship database was updated in 2005 and may be 
the way to go for the park boundaries.  I'll take a look and see if it's 
decent. 

As for the quality question.... it is really about scale and precision.  
generally look for a scale of 1:24,000 or larger.  check out the 
metadata for this info.  anything smaller than 1:100,000 will probably 
be too coarse for osm purposes.  to check precision, Tyler has the right 
idea... you can see inholdings from the aerial photography and 
boundaries typically follow streams and roads.

Kevin

Disclaimer:  I worked on the Georgia GAP and the Southeastern GAP 
projects, so I might be a little biased :)

Tyler wrote:
>
>>     I did a quick web search and found that the US National Park
>>     Service maintains a website with a large collection of GIS data,
>>     including park boundaries and campgrounds:
>>
>>     http://www.nps.gov/gis/data_info/park_gisdata/hi.htm
>>
>>     How do people go about evaluating the quality of data that is
>>     being considered for import? �I'm not sure there is a better
>>     source for US National Park boundaries than the NPS itself. �It's
>>     not like it's possible to survey the boundaries by observations
>>     on the ground. �The only way I was able to even determine that
>>     the previous import was problematic is that places I knew to be
>>     just inside the park boundaries appeared just outside the
>>     imported park boundaries.
>     this data isn't much better either. It may be good for some parks.
>     if you can verify the data is good then import.
>
>
> Sometimes the USFS has better NPS boundaries than the NPS (I don't 
> even try to figure it out). Also, a cursory look on the wiki page for 
> potential data sources would have brought up both the NPS and USFS 
> data 
> sources�http://wiki.openstreetmap.org/wiki/Potential_Datasources#US_Forest_Service
>
> I've only kind of looked at the HI state data, but there may be some 
> stuff in there (the large landowners and reserve maps both look pretty 
> coarse, though)
> �
>
>     I don't mean to belabor the point, but how do people typically
>     evaluate the quality of data that is essentially nothing more than
>     imaginary lines on a map?
>
> �
> Sometimes it's easy if you know the area. "Hey, I know the park 
> doesn't actually include all of those houses, because they're not 
> inholdings" Sometimes the boundaries are "to the thalweg of Big River" 
> and when you see that for Big River they have what looks like a "Z" 
> rather than an intricate meandering river, you know they're not great 
> (same goes for roads, shorelines and such). The best data for any 
> particular boundary tends to be from the county�(in WA state)�or 
> property taxing authority because they greatly care who owns what, and 
> where so they know how much to charge in the way of taxes. Since the 
> state and federal government don't pay property taxes the 
> inter-state/federal boundaries aren't necessarily great, but the 
> federal/state to private landowner boundaries are fantastic. If you 
> really have a question, hunting down a parcel map may be the way to go.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20091207/2d7ff825/attachment.html>