microsoft/USBuildingFootprints
Computer generated building footprints for the United States
repo name | microsoft/USBuildingFootprints |
repo link | https://github.com/microsoft/USBuildingFootprints |
homepage | |
language | |
size (curr.) | 338 kB |
stars (curr.) | 1424 |
created | 2018-06-13 |
license | Other |
Introduction
This dataset contains 125,192,184 computer generated building footprints in all 50 US states. This data is freely available for download and use.
License
This data is licensed by Microsoft under the Open Data Commons Open Database License (ODbL)
FAQ
What the data include:
125,192,184 building footprint polygon geometries in all 50 US States in GeoJSON format.
What is the GeoJson format?
GeoJSON is a format for encoding a variety of geographic data structures. For Intensive Documentation and Tutorials, Refer to GeoJson Blog
Creation Details:
The building extraction is done in two stages:
- Semantic Segmentation – Recognizing building pixels on the aerial image using DNNs
- Polygonization – Converting building pixel blobs into polygons
Semantic Segmentation
DNN architecture
The network foundation is ResNet34 which can be found here. In order to produce pixel prediction output, we have appended RefineNet upsampling layers described in this paper. The model is fully-convolutional, meaning that the model can be applied to an image of any size (constrained by GPU memory, 4096x4096 in our case).
Training details
The training set consists of 5 million labeled images. Majority of the satellite images cover diverse residential areas in the US. For the sake of good set representation, we have enriched the set with samples from various areas covering mountains, glaciers, forests, deserts, beaches, coasts, etc. Images in the set are of 256x256 pixel size with 1 ft/pixel resolution. The training is done with CNTK toolkit using 32 GPUs.
Metrics
These are the intermediate stage metrics we use to track DNN model improvements and they are pixel based. The pixel error on the evaluation set is 1.15%. Pixel recall/precision = 94.5%/94.5%
Polygonization
Method description
We developed a method that approximates the prediction pixels into polygons making decisions based on the whole prediction feature space. This is very different from standard approaches, e.g. the Douglas-Peucker algorithm, which are greedy in nature. The method tries to impose some of a priori building properties, which is, at the moment, manually defined and automatically tuned. Some of these a priori properties are:
- The building edge must be of at least some length, both relative and absolute, e.g. 3 meters
- Consecutive edge angles are likely to be 90 degrees
- Consecutive angles cannot be very sharp, smaller by some auto-tuned threshold, e.g. 30 degrees
- Building angles likely have very few dominant angles, meaning all building edges are forming an angle of (dominant angle ± nπ/2)
In near future, we will be looking to deduce this automatically from existing building information.
Metrics
Building matching metrics:
Metric | Value |
---|---|
Precision | 99.3% |
Recall | 93.5% |
We track various metrics to measure the quality of the output:
- Intersection over Union – This is the standard metric measuring the overlap quality against the labels
- Shape distance – With this metric we measure the polygon outline similarity
- Dominant angle rotation error – This measures the polygon rotation deviation
On our evaluation set contains ~15k building. The metrics on the set are:
- IoU is 0.85, Shape distance is 0.33, Average rotation error is 1.6 degrees
- The metrics are better or similar compared to OSM building metrics against the labels
Data Vintage
The vintage of the footprints depends on the vintage of the underlying imagery. Because Bing Imagery is a composite of multiple sources it is difficult to know the exact dates for individual pieces of data.
How good are the data?
Our metrics show that in the vast majority of cases the quality is at least as good as data hand digitized buildings in OpenStreetMap. It is not perfect, particularly in dense urban areas but it is still awesome.
What is the coordinate reference system?
EPSG: 4326
Will there be more data coming for other geographies?
Maybe. This is a work in progress.
Why is the data being released?
Microsoft has a continued interest in supporting a thriving OpenStreetMap ecosystem.
Should we import the data into OpenStreetMap?
Maybe. Never overwrite the hard work of other contributors or blindly import data into OSM without first checking the local quality. While our metrics show that this data meets or exceeds the quality of hand-drawn building footprints, the data does vary in quality from place to place, between rural and urban, mountains and plains, and so on. Inspect quality locally and discuss an import plan with the community. Always follow the OSM import community guidelines.
External References
The building data are featured in a recent NYTimes article
A Vector Tile implementation of the data is hosted by Esri
State | Number of Buildings | Unzipped MB |
---|---|---|
Alabama | 2,460,404 | 526 |
Alaska | 110,746 | 26 |
Arizona | 2,555,395 | 584 |
Arkansas | 1,508,657 | 321 |
California | 10,988,525 | 2,537 |
Colorado | 2,080,808 | 466 |
Connecticut | 1,190,229 | 258 |
Delaware | 345,907 | 75 |
District Of Columbia | 58,329 | 13 |
Florida | 6,903,772 | 1,521 |
Georgia | 3,873,560 | 825 |
Hawaii | 252,891 | 56 |
Idaho | 883,594 | 198 |
Illinois | 4,855,794 | 1,033 |
Indiana | 3,268,325 | 700 |
Iowa | 2,035,688 | 427 |
Kansas | 1,596,495 | 339 |
Kentucky | 2,384,214 | 500 |
Louisiana | 2,057,368 | 448 |
Maine | 752,054 | 160 |
Maryland | 1,622,849 | 344 |
Massachusetts | 2,033,018 | 438 |
Michigan | 4,900,472 | 1,045 |
Minnesota | 2,815,784 | 606 |
Mississippi | 1,495,864 | 321 |
Missouri | 3,141,265 | 662 |
Montana | 762,288 | 168 |
Nebraska | 1,158,081 | 245 |
Nevada | 932,025 | 212 |
New Hampshire | 563,487 | 122 |
New Jersey | 2,480,332 | 528 |
New Mexico | 1,011,373 | 231 |
New York | 4,844,438 | 1,035 |
North Carolina | 4,561,262 | 963 |
North Dakota | 559,161 | 121 |
Ohio | 5,449,419 | 1,164 |
Oklahoma | 2,091,131 | 455 |
Oregon | 1,809,555 | 408 |
Pennsylvania | 4,850,273 | 1,034 |
Rhode Island | 366,779 | 78 |
South Carolina | 2,180,513 | 463 |
South Dakota | 649,737 | 138 |
Tennessee | 3,002,503 | 638 |
Texas | 9,891,540 | 2,141 |
Utah | 1,004,734 | 226 |
Vermont | 345,911 | 75 |
Virginia | 3,057,019 | 643 |
Washington | 2,993,361 | 675 |
West Virginia | 1,020,031 | 213 |
Wisconsin | 3,054,452 | 654 |
Wyoming | 380,772 | 83 |
Contributing
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Legal Notices
Microsoft, Windows, Microsoft Azure and/or other Microsoft products and services referenced in the documentation may be either trademarks or registered trademarks of Microsoft in the United States and/or other countries. The licenses for this project do not grant you rights to use any Microsoft names, logos, or trademarks. Microsoft’s general trademark guidelines can be found at http://go.microsoft.com/fwlink/?LinkID=254653.
Privacy information can be found at https://privacy.microsoft.com/en-us/
Microsoft and any contributors reserve all others rights, whether under their respective copyrights, patents, or trademarks, whether by implication, estoppel or otherwise.