[Talk-us] NHD data extract

[Ben Supnik]

Hi Y'all,

 From what I can tell:

- Every water body does get a reach ID.  I've seen nulls in this file 
but haven't yet figured out what they are...in local sample areas, all 
water bodies have reach IDs.

- If there is linkeage between areas and flow lines (which I _thought_ 
there was when reading the docs this morning) I don't see it when 
browsing the real data.

- I can confirm that areas cross sub-basin boundaries.  (I downloaded 
the sub-basin shapefiles to check.)

I'm not sure where this leaves us...sub basins are small and manageable 
but don't partition the data particularly well (in that it looks like 
we'd need an expensive spatial check for rivers).  Users also don't 
necessarily know their sub-basin code unless they can find an online 
source to browse or view shapefiles.

Richard's idea of building an NHD tile map for tracing seems very 
do-able, but it wouldn't save a ton of time - every water feature would 
have to be hand-traced, even though we do have them in vector form 
already.  But I'm not sure that anything other than tile maps provide 
the level of user simplicity I was hoping for, e.g. being able to find 
just the part of the data you want to import in a form that's ready for 
import.

cheers
Ben


On 4/26/11 9:58 AM, James Umbanhowar wrote:
> On Tuesday 26 April 2011 09:35:00 Ian Dees wrote:
>> On Tue, Apr 26, 2011 at 8:30 AM, Ben Supnik<bsupnik at xsquawkbox.net>  wrote:
>>> Hi Ian,
>>>
>>> Where on the OSM servers is the current NHD data, and in what format?  I
>>> didn't see it referenced in the wiki work-flow.
>>
>> They're currently only used to render TopOSM and aren't available via HTTP
>> or whatnot. I had plans to convert it all to OSM but ran into the problem
>>
>> you're seeing below:
>>>   - Not all of the data types contain enough information to split like
>>>
>>>> this (last I checked the linear features were the only ones with reach
>>>> code. Polygonal features don't contain subbasin information)
>>>
>>> I am looking at this now.  Some of the polygonal lakes definitely do
>>> contain reach codes, others contain NULL.  From what I can tell, there
>>> are fcodes that indicate that there is no reach code (or any meta data).
>>>
>>> For the polygonal "area" data (which includes large rivers) there are
>>> indeed no reach codes. :-(
>>
>> If I remember correctly the area data has some sort of ID which links it to
>> the waterway (which has a reach code). The area data is what wraps a
>> waterway when it has a width greater than some standard "too wide for a
>> single line" width.
>
> Some of the areas, namely large river areas, cross subbasin boundaries so this
> might be why they cannot be localized to one subbasin.  This would be an issue
> if there were to be one file per subbasin.  Either the entire riverbank would
> need to be assigned to one subbasin or it would need to be split at the
> subbasin boundaries.
>
> This might also be the case for waterbodies.  I recall when I imported the
> coastal NC data there were many wetlands that crossed subbasin boundaries and
> were duplicated.
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

-- 
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://www.x-plane.com/blog/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: x-plane-scenery at yahoogroups.com
Developer mailing list: x-plane-dev at yahoogroups.com