[Talk-us] NHD imports

Ben Supnik bsupnik at xsquawkbox.net
Mon Oct 29 14:04:09 GMT 2012


Hi Y'all,

First, I'm sorry that I didn't jump into this thread earlier.  I am the 
graphics lead on X-Plane, and for our latest version we switched from 
TIGER+VMAP0+swbd to OSM for our vector water body and road data.  In the 
case of the US, this is perceived as a step backward by our users 
because TIGER, while not as accurate as a lot of the OSM water data, is 
reasonably complete.  Now that we use OSM, we are "missing" lakes that 
were present in older sim versions.

At the time the consensus on various lists about importing was that 
individual authors should import relatively small areas (e.g. single 
water sheds) and check the import against existing data, rather than 
simply blasting in the entire data set.  So I wanted to solve two 
problems to make things easier for users who had time and motivation but 
not data processing skills:

1. Getting NHD data.  At the time the NHD data was not available in 
shape-file format; some very nice person at the USGS basically burned me 
DVDs of the whole data set and mailed them to me, because the data was 
not online.

2. The conversion required running a non-GUI tool, which meant having 
command line skills, etc.

So I ran the import script over the entire data set and uploaded the 
resulting .osm files so individuals could use them.  There was a third 
step I was hoping could be solved: if you new to OSM, importing data 
isn't trivial.  Richard Fairhurst had a cool feature in Potlatch 2 where 
PL2 could be told of the presence of a vector layer and import it 
visually.  But I was never able to get the data to work with PL2.

I had to put the whole project on hold as X-Plane's ship date loomed 
closer and things went from crazy to really-freaking-crazy at work.

So to answer a few of Paul's questions:

> - They're of 2011 data, not the latest NHD data

Yep -- at the time I started the project it was a rip of 'latest', but 
that was a while ago. :-)

> - I wasn't able to find a rules file from bsupnik for the conversion, so
> they can't be rerun with latest data. He hasn't been active on the lists
> since 2011 and hasn't replied

I used shp-to-osm-0.8.2, jar'd by someone else (I am not a big java 
nerd, sorry) and the latest rules at the time from the Wiki.  If it is 
useful, I can send anyone who wants them a rip of the rules file I was 
using at the time and/or the JAR, buuuut...

> - The NHD data model changed since 2011

Yeah, I was something like that a few months after I put this down and 
went "oh hell...".  I haven't had time to look at what happened; is the 
data model a major revision to the point where everything I did makes no 
sense, or is it just renaming of fields?

Other issues about the import:
- I wouldn't say it is "split" from multiple files - rather I would say 
it is not joined - that is, the splits are the sub-basin splits that I 
think persist in the NHD.  Actually, I take that back - I think the tool 
chain intentionally avoids really huge OSM entities to avoid imports 
that can fail.

- There should be OSM codes like waterway=bla on at least -some- of the 
data.  The import program rules from the time did include FCODE and 
FTYPE and had no facility to drop entities that had only NHD but no OSM 
tags.  At the time this was also considered not-so-good, but I wasn't in 
a position to rebuild the tool.

Finally, just my 0.02: I am not an OSM expert and not an import expert 
buuut in my uninformed opinion, having original 'foreign' keys on an 
imported database isn't very useful.  The import guideline is to sanely 
merge the import with existing data, and the goal is to create something 
'osm native' when done, hence the importance of OSM tags and the notion 
of not importing data with no OSM meaning.

I think OSM really needs to be treated as one giant layer with 
heterogenious tags.  Imagine that a lake is missing from NHD.  A user 
opens potlatch and draws it, puts water=lake, and walks away, no FCODE 
or GNIS_ID or anything like that.  How can a consumer of OSM data handle 
this case?  Only by looking at semantic data like water=lake, and by 
analyzing the union of all OSM data that has 'interesting' tags.

Now we go to re-import NHD - is this ever going to happen?  (First: 
given how hard it's been to get NHD in even once, I am skeptical. :-) 
Every watershed has to be hand re-merged again.

Where I'm going with this is: I think imports should not be viewed as 
'layers' into OSM; if you ever want to look at NHD with a layer, export 
OSM into your favorite GIS, import NHD into your GIS too and now you 
have layers.  OSM imports are destructive merges and need to be 
carefully managed as such, with the target data format being OSM-centric.

So at the time I was annoyed that we couldn't just import all of NHD at 
once and 'get lakes everywhere' but while that would get a lot of 
waterbodies into empty places, it's probably not good for OSM or the US 
mapping community.

Okay, that's the end of my rant, which is probably either something 
everyone else already knows or completely wrong or both. :-)  Poke me if 
you have more q's or need materials....I think I still have the original 
raw 2011 NHD on DVD if anyone wants it, although it is now stale.

cheers
Ben


-- 
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



More information about the Talk-us mailing list