Re: [Talk-us] UVM-SAL Buildings
The locals and the data have spoken; I'm dropping the building imports for MD, PA and VT. My goal here was to rely on automated processes to get the data into shape, and I fear that even after size filtering, conflation and node removal the building footprints are mostly not up to the level of accuracy desired by the community. Too much manual cleanup is still required for a series of datasets that ultimately comprise over half a million features. Here's the MD subset, taken as far as I could without node-by-node adjustment: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_2.osm It's useful to note that - as land cover - the datasets from UVM-SAL are of unbelievably high quality. We in the LULC classification world have been suitably impressed with the object-based results from that team. However, OSM is a good example of a lingering inflection point between GIS and Survey scales. When it comes to building footprints, the desired quality includes right angles at corners and ways aligned parallel with walls (such a high bar!). This is a good distinction for me (and others) to keep in mind for the future as classification technology improves. Thanks to all for your input and guidance. I'm heading back to the drawing board. -Bill P.S. Josh, the conflation plugin hung for me on startup - three tries using JOSM on Ubuntu 12.04 with 2GB RAM. I'll give it a shot on a windows box with 8GB RAM later this week. -- William Morris Cartographer (802)-870-0880 wboyk...@geosprocket.com Twitter: @vtcraghead GeoSprocket LLC, Burlington VT www.geosprocket.com On Fri, Jun 1, 2012 at 12:53 PM, William Morris wboyk...@geosprocket.com wrote: 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): http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_bld_large.zip Thanks! -B On Thursday, May 31, 2012, Josh Doe wrote: On Thu, May 31, 2012 at 9:25 PM, William Morris wboyk...@geosprocket.com wrote: 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: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm Thanks for sharing. Spatial accuracy is pretty good for an automated process (worst I saw was 5m, usually more like 1 to 2m), though not as good as could be done (very laboriously) by hand given the resolution of the Bing imagery. I'd tend to say this shouldn't be uploaded en masse, but rather somewhat selectively, but I'll let the locals make that call. There a few issues I see which include: * Multipolygons aren't tagged with type=multipolygon, and the building=yes tags should be on the relation, not on the constituent (inner and outer) ways * AREA and PERIMETER should not be included as they can be calculated, and LandCover should not be included unless you can map it to a sensible (preferably already in use) tag, and since it's all 5 I'm guessing that's taken care of by building=yes * Ways are overnoded quite a bit, so run Douglas-Peucker first, experimenting with epsilon between 1m and 2m I've been slowly making improvements to the JOSM conflation plugin, with one goal being to facilitate the conflation of data like this with OSM. If you could provide a version of this file before excluding features which overlap existing OSM features, I'd like to try it out with the plugin to see if it produces useful results. Even better would be if you could take a look at the plugin yourself and suggest what enhancements would make it work for this use case. Note there are a few changes that aren't in the latest JAR available through JOSM. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
* William Morris wboyk...@geosprocket.com [2012-05-31 21:25 -0400]: 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: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm I share the reservations already expressed about the nodiness and blobbiness of the buildings. Here's one set of buildings, shown against Maryland's aerial imagery: http://static.aperiodic.net/tmp/md-mo-bldgs.png I'm not convinced that a county full of blobs like that will look good on the map and, thus, whether it would be an improvement over letting mappers put the buildings in as they get to them. I'm more comfortable with things like the building import done a few months ago around Salisbury in eastern Maryland where the data is much cleaner and, I think, better serves as a basis for further improvements from local mappers. I think that this level of accuracy, while reasonably-well-suited to landcover data, isn't really good enough for buildings. I'm also over in Baltimore County, so I'd like to hear what other regional mappers think. Some steps I've taken to make it community-friendly include: - Removed all buildings that intersected existing OSM features Definitely an important step. Thank you. - Removed all buildings smaller than 5000 square meters in area, since those residential structures weren't being very well-detected anyway There's not really a good cutoff for this, though. I saw a couple of housing developments with blocks of townhouses where random sets of townhouses were missing. Presumably the missing ones fell below your threshold while most of the blocks didn't. It might be useful to go much higher and target just the largest buildings (which would also be the more significant landmarks). Over all of your data, what does the distribution of building areas look like? -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Go climb a gravity well! --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
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): http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_bld_large.zip Thanks! -B On Thursday, May 31, 2012, Josh Doe wrote: On Thu, May 31, 2012 at 9:25 PM, William Morris wboyk...@geosprocket.com wrote: 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: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm Thanks for sharing. Spatial accuracy is pretty good for an automated process (worst I saw was 5m, usually more like 1 to 2m), though not as good as could be done (very laboriously) by hand given the resolution of the Bing imagery. I'd tend to say this shouldn't be uploaded en masse, but rather somewhat selectively, but I'll let the locals make that call. There a few issues I see which include: * Multipolygons aren't tagged with type=multipolygon, and the building=yes tags should be on the relation, not on the constituent (inner and outer) ways * AREA and PERIMETER should not be included as they can be calculated, and LandCover should not be included unless you can map it to a sensible (preferably already in use) tag, and since it's all 5 I'm guessing that's taken care of by building=yes * Ways are overnoded quite a bit, so run Douglas-Peucker first, experimenting with epsilon between 1m and 2m I've been slowly making improvements to the JOSM conflation plugin, with one goal being to facilitate the conflation of data like this with OSM. If you could provide a version of this file before excluding features which overlap existing OSM features, I'd like to try it out with the plugin to see if it produces useful results. Even better would be if you could take a look at the plugin yourself and suggest what enhancements would make it work for this use case. Note there are a few changes that aren't in the latest JAR available through JOSM. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
From: Phil! Gold [mailto:phi...@pobox.com] Subject: Re: [Talk-us] UVM-SAL Buildings * William Morris wboyk...@geosprocket.com [2012-06-01 12:53 -0400]: is orthogonalization worthwhile in this case? I'm not sure it is. I tried using JOSM's orthogonalization tool on a number of buildings and every time got a result that was worse than the original data in terms of being misaligned with the imagery. Most of them ended up with lines rotated close to 45 degrees from the actual building's walls (i.e. JOSM's orthogonalization was almost maximally bad in this case). JOSM's orthogonalization can sometimes give very unusual results. If you have a bunch of buildings in an area all aligned if you select the buildings, select two nodes in a line (e.g. nodes from the street where the buildings are aligned with the street) and then orthogonalize it will do everything relative to the line joining those nodes which will often give better results. I'm not sure that the above method would actually help in this import. It might be an inherent problem with the data that the buildings end up blobby. Personally, I'm coming down on the side of it's too blobby as-is. Perhaps there's some way to make the building-recognition algorithm make less blobby buildings? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[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: 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. -Bill Morris (vtcraghead) Burlington, VT -- William Morris Cartographer (802)-870-0880 wboyk...@geosprocket.com Twitter: @vtcraghead GeoSprocket LLC, Burlington VT www.geosprocket.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
On Thu, May 31, 2012 at 9:25 PM, William Morris wboyk...@geosprocket.com wrote: 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: http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm Thanks for sharing. Spatial accuracy is pretty good for an automated process (worst I saw was 5m, usually more like 1 to 2m), though not as good as could be done (very laboriously) by hand given the resolution of the Bing imagery. I'd tend to say this shouldn't be uploaded en masse, but rather somewhat selectively, but I'll let the locals make that call. There a few issues I see which include: * Multipolygons aren't tagged with type=multipolygon, and the building=yes tags should be on the relation, not on the constituent (inner and outer) ways * AREA and PERIMETER should not be included as they can be calculated, and LandCover should not be included unless you can map it to a sensible (preferably already in use) tag, and since it's all 5 I'm guessing that's taken care of by building=yes * Ways are overnoded quite a bit, so run Douglas-Peucker first, experimenting with epsilon between 1m and 2m I've been slowly making improvements to the JOSM conflation plugin, with one goal being to facilitate the conflation of data like this with OSM. If you could provide a version of this file before excluding features which overlap existing OSM features, I'd like to try it out with the plugin to see if it produces useful results. Even better would be if you could take a look at the plugin yourself and suggest what enhancements would make it work for this use case. Note there are a few changes that aren't in the latest JAR available through JOSM. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] UVM-SAL Buildings
I have a few specific comments, and some more general ones From: William Morris [mailto:wboyk...@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. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
