GlobalMLBuildingFootprints: Worldwide Building Data and Download Guide

GlobalMLBuildingFootprints Coverage and Intended Use

GlobalMLBuildingFootprints addresses the scarcity of open building geometry at global scale. The README states that the dataset contains 1.4 billion buildings detected from Bing Maps imagery acquired between 2014 and 2024. Named imagery sources include Maxar, Airbus, IGN France, and Vexcel. This scope makes the repository relevant to geospatial engineers working with mapping, machine learning datasets, spatial indexing, urban analysis, or broad background geometry. The README does not describe a narrower audience, a particular programming interface, or a complete list of downstream use cases.

The important distinction is that this repository presents data publication and distribution, not an end-user library with a documented API. Based on the repository layout, the top-level `scripts/` directory contains supporting material and `examples/example_building_footprints.ipynb` provides an example notebook. The contents of those files are not included in the README, so the article cannot confirm their commands, dependencies, or processing sequence. The README identifies `dataset-links.csv` as the distribution point, while the actual footprint data is reached through links associated with tiles and regions.

Coverage is broad, but breadth is not the same as uniform completeness. The README describes contributions concentrated in particular countries during several updates, including India, Brazil, Turkey, Greece, France, the United States, and other regions. That pattern shows why users should examine the target geography rather than treating worldwide coverage as equivalent local density. The repository does not provide accuracy statistics, minimum building-size thresholds, positional error bounds, or a formal completeness measure.

dataset-links.csv and the Tile Distribution Model

The distribution model centers on `dataset-links.csv`. The update history says that the current global dataset covers 30,340 tiles across 225 regions. That organization allows a user to work at regional or tile scale instead of downloading every global footprint at once. The README does not state the CSV column names, tile naming scheme, coordinate reference system, geometry encoding, or file extension of each linked artifact. Those details must be taken from the actual CSV and downloaded files rather than inferred from the repository name.

The data publication process has changed since the first releases. On 2026-07-24, hosting moved from `minedbuildings.z5.web.core.windows.net` to `bfppub.blob.core.windows.net`. The README explicitly says that older versions will not be moved, while future updates will be available at the new location. This is an operational boundary for automation. Code that assumes the former host or the historical path can stop resolving data even while the project remains active.

Updates can edit existing coverage as well as add new records. The history refers to both new footprints and footprint edits. On 2024-12-02, the merge logic changed to update tiles at LOD 19 instead of LOD 15, with the stated purpose of reducing visible update boundaries. That note reveals a tiling and merge mechanism, but it does not explain how source observations become polygons, how conflicts are selected, or how a new tile replaces an earlier one. Users who cache tiles need an explicit version policy, although the repository does not provide one in the README.

Downloading Tiles and Running a First Data Use

The repository does not document an installation command because it is presented as a downloadable dataset rather than a documented Python package. There is also no `requirements.txt` or installation tutorial in the README. Start by opening the current manifest rather than an older URL:

https://bfppub.blob.core.windows.net/%24web/2026-08-13/dataset-links.csv

The README says this manifest was updated on 2026-08-13 as part of a refresh in which 1,945 of the 30,340 tiles were updated. Use the manifest to identify the link associated with the region or tile needed for the first use. The README does not expose the manifest's columns, so it would be unsafe to provide parsing code with invented field names. A valid first workflow is therefore limited to inspecting the CSV structure, selecting the documented target tile, and downloading that linked artifact from the stated location.

After downloading a tile, inspect its actual file format and geometry fields before loading it into GIS or Python tooling. The repository states that the data consists of building footprints, and later update notes mention height estimates, but it does not clearly state whether every current tile contains height data. The example notebook named `examples/example_building_footprints.ipynb` may demonstrate a usage path, but the README does not describe its contents. No runtime, coordinate system, parser command, or notebook output can therefore be attributed to the project documentation.

Imagery Detection, Geometry Quality, and Refresh Boundaries

The README confirms that buildings were detected from satellite or aerial imagery, but it does not publish the model architecture, training procedure, confidence score, or post-processing rules. Calling the repository a machine-learning project based on its name would go beyond the documented architecture. The only verifiable pipeline statement is that Bing Maps imagery was processed to produce building footprints, with imagery attributed to providers such as Maxar, Airbus, IGN France, and Vexcel.

Several update notes distinguish footprint additions from edits and height estimates. For example, the 2026-07-24 update added 431,000 building footprints and 431,000 height estimates derived from 2025 Vexcel imagery. Earlier updates introduced footprint edits without corresponding height estimates. This means consumers should not infer a stable one-to-one relationship between every footprint and a height value. The README also does not document how heights are represented or how their accuracy was assessed.

Satellite-derived polygons have application-specific failure modes, even though the README does not enumerate error categories. Users should not assume that a polygon corresponds to a surveyed parcel, that visible roofs equal legal building boundaries, or that every structure is detected. The repository does not publish a documented rollback procedure, positional accuracy tolerance, or region-by-region quality assessment. The December 2024 change at LOD 19 is evidence that merge behavior has been adjusted, but it does not guarantee seam-free or error-free updates.

Refresh Operations and Licensing Boundaries

This is an operationally refreshed dataset rather than a fixed release archive. The update record includes changes in January and July 2026, including a global source-of-truth refresh on 2026-08-13. The repository is not archived, and its last push was on 2026-08-14. There are no GitHub releases, so release versioning cannot be used as the primary upgrade mechanism. The manifest URL and linked artifacts must be managed directly.

The refresh history documents substantial additions and edits. It records 128 million footprint edits on 2024-03-26, 58 million on 2024-03-01, and 47 million on 2024-02-01, while later releases cover smaller country-specific updates. A team that reprocesses all tiles will therefore face changing geometry and potentially changing height coverage. The repository does not document checksums, an immutable snapshot policy, or a migration process for stored derivatives. Those details need verification from the files themselves before production automation depends on stable tile identities.

There are also two licensing descriptions that must be kept distinct. Repository metadata classifies `LICENSE` as a custom license that GitHub cannot classify, directing readers to the file. The README says the downloadable building-footprint data is available under CDLA Permissive 2.0. Review the repository `LICENSE` and the applicable data terms for the intended distribution and use. This article does not interpret their legal effect.

When a Locally Maintained Building Layer Is the Better Alternative

For some projects, the better alternative is an internally maintained building-footprint layer built from organizational surveys, cadastral sources, local imagery, or a controlled collection process. The difference in approach is accountability. GlobalMLBuildingFootprints distributes detections derived from imagery gathered over a long period and supplied by several providers. A locally maintained layer may be smaller, but the organization can document its source dates, review rules, update history, and treatment of conflicting boundaries.

GlobalMLBuildingFootprints is the more practical choice when the application needs broad geographic reach and accepting refresh-driven edits is manageable. A local layer is more appropriate where building outlines affect regulated transactions, cadastral interpretation, valuation, or other decisions requiring local authority and review. Another suitable alternative is existing authoritative vector data in the target jurisdiction, but the README does not compare its geometry with any named cadastral source, so no superiority claim can be made.

The decision should be made per region. Confirm that the manifest covers the area, inspect a representative tile, establish whether heights are present, and understand how refreshes affect stored geometry. The global footprint count does not answer those local questions.

Editorial conclusion

GlobalMLBuildingFootprints fits teams that need a broad, regularly refreshed building-vector source and can independently verify its geometry and coverage. It is a poor fit for cadastral decisions, applications requiring documented local accuracy, or engineers who need a fully specified schema and extraction pipeline. Before adoption, inspect the linked regional tile for the target area, confirm that the `LICENSE` file permits the intended use, and check whether missing or edited footprints are acceptable for the application. The repository is not archived and its last push was on 2026-08-14.

Frequently asked questions

Official sources

1. Issues
2. microsoft/GlobalMLBuildingFootprints on GitHub
3. README