[Talk-us] What to do with unnamed NHD streams
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:
> 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
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. 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.
: 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