[Talk-us] What to do with unnamed NHD streams

Paul Norman penorman at mac.com
Mon Oct 29 05:29:02 GMT 2012


> From: Michal Migurski [mailto:mike at teczno.com]
> Sent: Sunday, October 28, 2012 8:58 PM
> To: OpenStreetMap US Talk
> Subject: Re: [Talk-us] What to do with unnamed NHD streams
> 
> Does [NHD] all come in shapefile form? The simplification would be a
> relatively easy (though time-consuming) task for PostGIS on a server
> with sufficient storage, outputting new shapefiles for ogr2osm. I can
> help with this using one of our office servers that we use for such
> tasks.

It comes in .mdb or .gdb form. These could be loaded into postgis and I've
considered doing it. My home server has the storage and cores to do it, but
I don't think it would help.

The problem is you need to convert to .osm and *then* simplify. If you do
this in the other order you have problems where one object intersects
another (e.g. because they share a geometry for a portion of them). You end
up simplifying away the intersection points and your resulting ways won't
end up correctly sharing nodes.

The most common example of this is when a stream meets a lake. At the
meeting point you have a FCode 55800 from NHDFlowline in the water, a FCode
4600x from NHDFlowline on the land side and a FCode 390xx or 436xx from
NHDArea as the bounds of the lake. Without simplification the output will
have the three ways sharing a node at the intersection point. If you
simplify before converting you could simplify away the point on the NHDArea
and then you'll no longer have the node sharing.

You can run into similar issues where a simplification of a NHDFlowline
takes it away from a NHDPoint, resulting in the point no longer being on the
line.

I would *really* like to be able to simplify prior to ogr2osm as it would
dramatically decrease the size of the nodes data in-memory and decrease
conversion time, I just can't see how to do it prior to processing.

JOSM's simplify ways function works okay, although it doesn't deal with the
case of two ways sharing nodes very well.

> > 3. A lot of NHD is very minor streams "only of use to hydrologists."
> > There are streams that you would be hard pressed to locate if you were
> > there in person and in some cases they do not exist anymore.
> >
> > A sensible solution in any NHD translation may be to drop any FCode
> > 46003
> > (intermittent) streams without a name. It may also be worth dropping
> > FCode
> > 46006 (perennial) streams without a name.
> 
> Can these be simplified to a lower level of accuracy?

In principle yes, and I'll try it with JOSM. I'm not sure how it'd turn out.
I have a feeling it will still result in a lot of low-value ways. Perhaps
drop nameless 46003 which often don't correspond to anything noticeable and
use heavier simplification on 46006? I'm not convinced this would be a good
option, but I'll see how it looks in a couple basins.




More information about the Talk-us mailing list