So here's something to mull over while we all wait for the license upgrade:
http://dl.dropbox.com/u/23616645/Geosprocket_Share/umd_subset.osm That's an extract of the UVM-SAL building footprints I'd like to import for swathes of MD and PA. My workflow for killing existing feature conflicts actually went best without involving ESRI at all: 1.) In QGIS, Set up 0.2-degree import grid over new building coverage areas 2.) Pull down one grid cell worth of OSM data using the QGIS OSM plugin 3.) Add building footprint .shp, select all footprints that intersect OSM lines or polygons 4.) Switch selection, save as new .shp 5.) Run ogr2osm.py on new .shp (Special thanks to Andrew Guertin for running me through that process) 6.) Open new .osm file in JOSM, add building tags, upload. 7.) Repeat for next import grid cell Tedious, but it'll get the job done. And a reminder: I do not intend to add any building footprint that conflicts with an existing feature, adhering to the OSM preference for user-added features over imports. Now soliciting thoughts, roadblocks, expressions of ennui, etc. Thanks! -Bill Morris ---------- William Morris Cartographer (802)-870-0880 [email protected] Twitter: @vtcraghead GeoSprocket LLC, Burlington VT www.geosprocket.com On Thu, Mar 22, 2012 at 9:35 PM, William Morris <[email protected]> wrote: > Ian, Honestly - and with a certain amount of shame - I had planned to just > pull both sets of buildings into ArcMap and run location SQL (select from > UVM-SAL buildings where intersect with OSM buildings), then invert the > selection and export. It seemed like this approach is conservative toward > OSM feature preservation and might also be good for QA/QC in small batches. > Unfortunately I'm noticing that the cloudmade shapefile zips don't include > buildings. Moving on to the next idea . . . > > Josh, I would happily assist on the plugin if I knew the first thing about > Java. I'm more inclined to lean on GDAL/OGR in the backend, but I agree it > would be fantastic to have this functionality in the editors. > > -B > > > > On Thursday, March 22, 2012, Josh Doe <[email protected]> wrote: >> On Thu, Mar 22, 2012 at 4:23 PM, Ian Dees <[email protected]> wrote: >>> Personally, I'm most interested in discovering how you're planning on >>> doing >>> the conflict detection between the incoming data and existing OSM data. >>> The >>> import list has been interested in something like that for a long time >>> and >>> we haven't really had something that did it right. >> >> Sounds like this could be a good application of the conflation plugin >> I've been working on. I'm in the process of integrating the Java >> Topology Suite (JTS) and the Java Conflation Suite (JCS) which offers >> some pretty powerful matching features based on attributes (tags), >> distance, overlap, etc. Like others have said, this would still need >> to be done at a local level in small chunks, which is good since the >> plugin likely can't handle matching more than 5000 or so objects >> without taking forever. I'd be glad to have help on the plugin >> however, my nights and weekends have been pretty busy lately... >> >> -Josh >> _______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
