[Imports] [Talk-us] UVM-SAL Buildings

Paul Norman penorman at mac.com
Fri Jun 1 03:39:28 BST 2012

I have a few specific comments, and some more general ones

> From: William Morris [mailto:wboykinm at geosprocket.com]
> Subject: [Talk-us] UVM-SAL Buildings
> Howdy Folks,
> Trying this again, after a hiatus, here is a sample of a few hundred
> buildings from a UVM-SAL land use classification. In this case it's for
> an area just west of D.C. in Montgomery County, MD. I offer it for your
> consideration before I pull the import trigger:

Before importing, don't forget to follow the other steps in the import
guidelines about documenting it on the wiki.

> http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm
> Some steps I've taken to make it community-friendly include:
> - Removed all buildings that intersected existing OSM features
> - Removed all buildings smaller than 5000 square meters in area, since
> those residential structures weren't being very well-detected anyway
> - I hopehopehopehope the footprints survived their trip from QGIS
> through ogr2osm to JOSM (If there's anything wrong with the tags please
> let me know so I can solidify the process)
> Thanks again to Andrew Guertin for adapting ogr2osm so perfectly.
> Python has never been so easy.

I noticed the following issues:

The AREA and PERIMETER tags are superfluous - the area and perimeter can be
trivially computed from the geodata.

The LandCover tag also doesn't seem to serve any purpose as it only ever has
one value.

There are building=yes tags on ways in multipolygons - these should be on
the MP, not on the ways. Did you run it through ogr2osm and then select
type:way in JOSM by any chance? It would be better to write a translation
file to apply the appropriate tags to the appropriate objects. If you did
this, try my version of ogr2osm at https://github.com/pnorman/ogr2osm and
let me know if the problem still occurs, since then it would be a bug.

The detection seems pretty good. I was only able to find one false-positive
and a couple places where buildings had merged together, as well as a couple
of places where one building ended up split.

Some of the ways seem a bit over-noded. Normally I'd suggest JOSM's simplify
way tool but I'm guessing there might be a more effective point in the
workflow to do this.

Buildings tend to be rectangular and have a lot of straight lines so it's
really noticeable where these don't. Errors which would not be particularly
noticeable on a forest or a lake become more so on buildings. I'm hesitant
to suggest a fix for this.

I'm also not sure about the usefulness of the data. If a user later comes
along and wants to improve it, it'd be faster to delete and recreate it than
to improve the ways.

More information about the Imports mailing list