Fantastic. I'll give the plugin a run, along with some de-noding (is orthogonalization worthwhile in this case?), and check back with folks. And here's the pre-filtered buildings file county-wide (in .shp format still):<div>

<br></div><div><a href="http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_bld_large.zip">http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_bld_large.zip</a><br><div><br>
</div><div>Thanks!</div><div>
<br></div><div>-B</div><div><br></div><div><span></span><br><br>On Thursday, May 31, 2012, Josh Doe  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 31, 2012 at 9:25 PM, William Morris<br>




<<a>wboykinm@geosprocket.com</a>> wrote:<br>
> Howdy Folks,<br>
><br>
> Trying this again, after a hiatus, here is a sample of a few hundred<br>
> buildings from a UVM-SAL land use classification. In this case it's<br>
> for an area just west of D.C. in Montgomery County, MD. I offer it for<br>
> your consideration before I pull the import trigger:<br>
><br>
> <a href="http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm" target="_blank">http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm</a><br>
<br>
Thanks for sharing. Spatial accuracy is pretty good for an automated<br>
process (worst I saw was 5m, usually more like 1 to 2m), though not as<br>
good as could be done (very laboriously) by hand given the resolution<br>
of the Bing imagery. I'd tend to say this shouldn't be uploaded en<br>
masse, but rather somewhat selectively, but I'll let the locals make<br>
that call.<br>
<br>
There a few issues I see which include:<br>
* Multipolygons aren't tagged with type=multipolygon, and the<br>
building=yes tags should be on the relation, not on the constituent<br>
(inner and outer) ways<br>
* AREA and PERIMETER should not be included as they can be calculated,<br>
and LandCover should not be included unless you can map it to a<br>
sensible (preferably already in use) tag, and since it's all 5 I'm<br>
guessing that's taken care of by building=yes<br>
* Ways are overnoded quite a bit, so run Douglas-Peucker first,<br>
experimenting with epsilon between 1m and 2m<br>
<br>
I've been slowly making improvements to the JOSM conflation plugin,<br>
with one goal being to facilitate the conflation of data like this<br>
with OSM. If you could provide a version of this file before excluding<br>
features which overlap existing OSM features, I'd like to try it out<br>
with the plugin to see if it produces useful results. Even better<br>
would be if you could take a look at the plugin yourself and suggest<br>
what enhancements would make it work for this use case. Note there are<br>
a few changes that aren't in the latest JAR available through JOSM.<br>
<br>
-Josh<br>
</blockquote></div>
</div>