RoadDetections: road geometry mined from satellite imagery

Mined road geometry released as open data

The framing in the README is unusual for a Microsoft repository. Bing Maps is releasing mined roads around the world, and the stated figure is 54.2M km of roads worldwide, with mining performed using Bing Maps imagery including Maxar and Airbus.

The data is described as freely available for download and use under the Open Data Commons Open Database License, which is the ODbL. That is a share-alike licence for databases, and it is the licence that matters for anyone who plans to build a derived product on top of the geometry.

The README also states a plan, and it is worth reading as a plan rather than as a shipped fact: the intention is to opensource both the neural network model and the geometry generation code in the first half of 2025. The repository does contain geomgen/ and model/ directories, so parts of that are visible, but the pipeline description below is documentation, not something you can run end to end from what the README states.

The project is aimed at anyone who needs road geometry at continental scale: mapping researchers, dataset builders, and people training their own models on road extraction.

Regional zip files, with the world set at 16.5 GB

The download table is organised by region rather than by country, and the README explains that the world is divided into subregions for better usability based on the United Nations geoscheme.

The regions are Australia and Oceania, the Caribbean, Central America, Central Asia, Eastern Africa, Eastern Asia, Eastern Europe, Middle Africa, Northern Africa, Northern America, Northern Europe, South America, Southeastern Asia, Southern Africa, Southern Asia, Southern Europe, Western Africa, Western Asia and Western Europe, plus a World archive that contains everything.

The numbers give a sense of the scale. The World archive is listed at 54225.2 in units of a thousand kilometres, which matches the 54.2M km headline, with a file size of 16564 MB. The largest regional entries are Northern America at 12990.6 thousand kilometres and 3865 MB, Eastern Europe at 4601.4 thousand kilometres and 1382 MB, and Western Europe at 3560.5 thousand kilometres and 1410 MB. The smallest are Eastern Asia at 153.9 thousand kilometres and 48 MB, and the Caribbean at 243.7 thousand kilometres and 76 MB.

One practical detail sits in the URLs. Every link points at a drop dated 2025.04.28 in a storage container, so the table describes one snapshot rather than a continuously updated feed, and there is no release history in the repository to roll back to.

Rows are an Alpha-3 code and a GeoJSON, separated by a tab

The FAQ section gives the file format, and it is a plain text format rather than a GIS interchange format.

Each file holds all the roads from a certain geographical region. Each row contains an Alpha-3 code and a GeoJSON of a road, separated with a TAB character, and the GeoJSON also contains a property called WidthMeters, an approximate width of the road in metres.

So a row looks like a country or region code, a tab, and a small GeoJSON object for one road segment. That is easy to stream and easy to parse, and it is also easy to get wrong: a consumer that expects one FeatureCollection per file will need to accumulate. Each row is a separate geometry rather than a per-file collection.

The Alpha-3 codes come from the IBAN country code list and the ISO 3166-1 alpha-3 codes, and the repository ships a mapping file, AlphaCodeToRegionName.tsv, to translate a code into a region name. The README warns that some smaller regions and disputed areas might have ambiguous codes, which is a real problem for anyone doing country-level aggregation on the data.

The GeoJSON format itself is the standard one, and the README points at geojson.org for the intensive documentation and tutorials.

Segmentation first, then a geometry pipeline

The data generation details describe two major stages, and the second is where the engineering effort sits.

The first stage is semantic segmentation, recognising road pixels on the aerial image using a Convolutional Neural Network. The second stage is geometry generation, a series of algorithms and processes that transform the output of the segmentation into roads in geometry format. The listed steps are image postprocessing, thinning, connectivity improvement, graph construction, finalising road shapes and network quality, and stitching road geojsons between neighbouring images where needed.

That list is a useful map of what has to happen between a pixel mask and a road network. Thinning turns a thick pixel band into a centreline. Connectivity improvement fixes the fragments that segmentation leaves behind. Graph construction is where the pieces become a network, and the stitching step is what makes a road continuous across the boundary of two adjacent images, which is the part that determines whether a route can be traced at all.

The final step, finalising road shapes and network quality, is also where the WidthMeters property comes from, and it is where a good deal of the judgement lives. None of these details are documented as tunable parameters, so for a user the pipeline is described rather than offered.

A fully convolutional network trained on 20,000 tiles

The network section is the most specific part of the documentation.

The architecture was based on UNet and ResNet, following the U-Net paper, the Res U-Net paper and a second Res U-Net paper. The model was trained on 512x512 images and is fully convolutional, which allows images of any size divisible by 64 to be processed, constrained by GPU memory, with 1088x1088 in their case.

The training set consists of 20000 labeled images, and the README says the majority of the satellite images cover diverse areas around the world, with the set enriched with samples from mountains, glaciers, forests, deserts, beaches and coasts. That enrichment list is the interesting part, because those are the terrains where a road model trained on easy terrain fails, and their presence in the training set is what makes the coverage claim plausible.

The images in the set are 1088x1088 pixels at 100 cm/pixel resolution, and the training is done with the Keras toolkit.

The 100 cm per pixel figure also bounds the output. A road at that resolution has a width of a few pixels, which is why the pipeline needs thinning and postprocessing rather than reading a centreline directly from the network, and it is a useful number to keep in mind when judging the WidthMeters values in the data.

Two metrics, one for pixels and one for connectivity

The metrics section explains that intermediate stage metrics are tracked to follow model performance, and it names two of them.

The pixel metric measures the performance of the convolutional network, and the APLS metric, Average Path Length Similarity, measures overall connectivity after the geometry generation stage. The README links to a write-up of the APLS metric for background.

Splitting the evaluation into those two stages is the right way to evaluate a pipeline like this. A network with a poor pixel metric produces a bad mask, and a good pixel metric does not guarantee a usable network, because the graph construction and connectivity repair stages can still break routes that a human would consider continuous. APLS is the metric that speaks to the thing an actual map user cares about, which is whether a path exists between two points.

The metrics table is truncated in the documentation available here, so the precision and recall values for the two metrics are not shown, and the README does not state what the current numbers are. Anyone who needs a quality figure for a region should measure it on the data rather than take it from the repository.

The repository holds a mapping file and two work directories

The top level of the repository is small: .gitattributes, .gitignore, AlphaCodeToRegionName.tsv, CODE_OF_CONDUCT.md, LICENSE, README.md, SECURITY.md, and three directories, geomgen/, images/ and model/.

Those three directories are where the interesting content sits, geomgen/ for the geometry generation work and model/ for the network side, with images/ holding the figures used in the documentation. The mapping file AlphaCodeToRegionName.tsv sits at the top level precisely because it is the file a consumer needs alongside the data.

The data itself is not in git. Every download link points at a storage container, and there are no GitHub releases, so the archives are the artefact and the repository is the documentation and the code. That arrangement makes sense for multi-gigabyte data, and it also means there is no version history to consult when a drop is superseded: the drop date in the URL is the only version marker.

The licence field for the repository is one GitHub cannot classify, and the README names the Open Data Commons Open Database License as the terms for the data. The LICENSE file in the repository is the place to read the actual text, and the CODE_OF_CONDUCT.md and SECURITY.md files follow the standard practice for a project published by a large organisation. The last push was on 2026-05-05, with the primary language listed as C# for the repository as a whole.

Editorial conclusion

Adopt RoadDetections if you need wide area road centreline geometry for research, training data or map production, and you can work with a tab separated GeoJSON layout and an ODbL share-alike obligation on the derived database. Skip it if you need a routing graph, live traffic or a licence that is simpler than a database licence, since the deliverable is geometry extracted from imagery rather than a network product. Before you build on it, download one regional zip and check the WidthMeters values and the Alpha-3 codes in AlphaCodeToRegionName.tsv, since small and disputed regions use ambiguous codes, and confirm that your pipeline can ingest GeoJSON per row rather than a single feature collection. The last push was on 2026-05-05 and the repository has no GitHub releases.

Frequently asked questions

Official sources

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