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

Paul Norman penorman at mac.com
Mon Oct 29 07:49:00 GMT 2012


> From: Michal Migurski [mailto:mike at teczno.com]
> Sent: Monday, October 29, 2012 12:04 AM
> To: OpenStreetMap US Talk
> Subject: Re: [Talk-us] What to do with unnamed NHD streams
> 
> On Oct 28, 2012, at 11:41 PM, Paul Norman wrote:
> 
> >> From: Michal Migurski [mailto:mike at teczno.com]
> >> Subject: Re: [Talk-us] What to do with unnamed NHD streams
> >>
> >> On Oct 28, 2012, at 10:29 PM, Paul Norman wrote:
> >>
> >>> 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.
> >>
> >> There are ways around this, by first de-duping the shared edges or
> >> nodes. Topology preservation is not terribly difficult if you prepare
> >> your data, for example by splitting lines and polygons at
> >> intersections (as in your lake example), simplifying only the parts
> >> and then reconstructing the original geometries.
> >
> > Do you have a link to an example of the PostGIS magic to do this? It's
> > beyond what I could do.
> 
> I implemented a version of this here:
> 	http://github.com/migurski/Bloch
> 	
> Without digging into the code too deeply, the short version is that you
> can use the intersection of two shapes to arrive at something like a
> topology. For a pair of polygons that share a border, the
> ST_Intersection() results in a linestring that forms the border, which
> you can ST_Difference from each border to get the remaining pieces. The
> expensive part is the gigantic pairwise comparison to come up with the
> full list of all feature pairs that touch each other or come really
> close.

I'll have a look tomorrow - I'm too tired to give it thought right now.

> > A slight complication I found is that you can't just go for
> > intersections but you also have to go to near intersections -
> > sometimes the NHD data is off by a couple cm. I don't know if this
> > will pose a practical issue for the simplification.
> 
> Possible to round every node position to 1e-7 degrees?

Yes - this is in fact what ogr2osm does. It internally nanodegrees and all
positions are integers, and it groups nodes within 100 nanodegrees by
default[1]. I'm not sure how to do this to a .mdb although it may be
possible to do when loading the files.

My initial thoughts are that if I'm loading into PostGIS I don't really want
to export out of it, I'd prefer to go immediately to ogr2osm. Currently I
don't have the ability to read from PostGIS in ogr2osm but I've considered
adding it and it shouldn't be hard.


[1]: It's late enough that I'm not 100% sure on the exact number of decimal
places used without checking.




More information about the Talk-us mailing list