[Talk-us] Addition of building footprints in selected U.S. and Canadian cities

William Morris wboykinm at geosprocket.com
Mon Apr 2 16:46:58 BST 2012


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
wboykinm at geosprocket.com
Twitter: @vtcraghead

GeoSprocket LLC, Burlington VT
www.geosprocket.com



On Thu, Mar 22, 2012 at 9:35 PM, William Morris
<wboykinm at geosprocket.com> 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 <josh at joshdoe.com> wrote:
>> On Thu, Mar 22, 2012 at 4:23 PM, Ian Dees <ian.dees at gmail.com> 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
>>



More information about the Talk-us mailing list