> From: Michal Migurski [mailto:m...@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:m...@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. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us