ATAK-Maps: a catalogue of map sources you can install into ATAK in one tap

Forty pointers to tile servers, and what ATAK does with them

ATAK-Maps is a curated, open collection of 40 satellite, topographic, nautical, trail and overlay map sources, and the mechanism is simpler than the name suggests.

Each entry is a MOBAC-format XML file, and each of those is a pointer to an online map or imagery source. ATAK reads the XML to display live imagery and to cache map areas for offline use. So the repository does not contain map tiles, it contains descriptions of where to fetch them, and the workflow described in the project is to pick a region and a quality, and ATAK downloads it for the field. The documentation calls that caching essential where connectivity is limited.

The collection is not affiliated with TAK.GOV, which the project states explicitly, and it requires ATAK 5.1 or newer.

The subject itself is worth a sentence. ATAK is a mapping application for situational awareness, and the set of sources here spans what a field user might want: US Geological Survey basemaps and imagery, Ordnance Survey outdoor and road layers, Esri clarity and topographic layers, Canadian Toporama, German basemap.de hillshade and colour DEM, Natural Resources Canada base maps, BLM land ownership layers, OpenSeaMap charts and seamarks, MTBMap.cz, Michelin, OpenTopo, CycleOSM, and a set of Google and Bing layers.

The Google and Esri entries in particular are worth a note about what this project is and is not. It is a list of pointers to publicly reachable tile endpoints. Whether a given provider permits that use is a question of their terms, and the project addresses the sharpest version of it explicitly under OpenStreetMap compatibility, where it says OpenStreetMap may restrict ATAK client access, that these maps are included for reference, and that solutions are being explored.

Three install routes, and the tak:// scheme is the reason for the 5.1 requirement

The installation story is the part of the project that is genuinely unusual, because it uses ATAK's own import scheme rather than a file manager.

The fastest route is per map. You open the catalog site on the ATAK device and tap Add to ATAK on any map, filtering by style, or you scan a QR from another screen. The whole set at once is a QR code, or a URL pasted into a browser on the device, which imports a data package with all 40 maps, kept in ATAK's Mission Package Tool so you can remove them later:

tak://com.atakmap.app/import?url=https%3A%2F%2Fjoshuafuller.github.io%2FATAK-Maps%2Fpack%2Fatak-maps-all.zip

The third route is manual: download the latest `atak-maps.zip` from the releases page and open it with ATAK's Import feature, with an install guide covering troubleshooting and offline caching.

The reason the 5.1 requirement exists is stated directly. ATAK 5.1 is the version that added the `tak://` import scheme, and without it the tap-to-install path does not exist. The documentation also explains a GitHub-specific limitation: GitHub cannot render a tappable `tak://` link, which is why the buttons live on the catalog site where they are tappable on-device, and why the QR code exists at all.

That is a coherent design. The one-tap flow is the product, and everything else, the ZIP for offline or air-gapped use and the manual import, exists for the cases where the one-tap flow cannot reach. The install guide being separate from the README is consistent with that, since the common path needs no documentation and the awkward paths do.

The catalogue in the README is generated, so it cannot drift from the XML

The map catalogue in the README is auto-generated from the XML files in the repository, and that single fact is what makes the project maintainable.

A hand-maintained list of map sources is a list that goes stale. Someone renames a layer, or a provider changes its zoom range, and the table keeps claiming the old values until a reader discovers otherwise in the field. Here the table is produced from the same files ATAK reads, so a change to a layer's XML and a change to the table are the same change.

The table's columns show how much detail is carried. Each row gives the provider, the map name, the zoom range from minimum to maximum, the tile type and the source protocol, and the source column distinguishes TMS from WMS and from Multi-Layer entries. The tile type column records the image format, png, jpg, PNG or JPG, with the inconsistent capitalisation coming from the source data.

The zoom ranges are the operationally interesting column, because they tell you what a layer is actually for. The USGS layers run from 0 to 15, Esri's World Topo runs 1 to 20, Ordnance Survey layers 0 to 16, Natural Resources Canada runs 0 to 23, the BC Wildfire perimeters go to 22, and NAIP, the USDA CONUS Prime aerial photography, stops at 17. A layer with a maximum zoom of 15 is a regional layer that goes blurry before it covers a city, and one that goes to 23 is usable at street level. Reading the column before choosing a layer saves a trip to a place where the map is useless.

The generation is marked in the file with `<!-- MAP_CATALOG_START -->` and `<!-- MAP_CATALOG_END -->` markers, and the same mechanism is likely what produces the per-map QR codes and the catalog site, which is described as being browsed and installed from, with a page for the maps and a packaged ZIP for the whole set.

A Python validator with a coverage floor, not just XML files

The repository is not only a pile of XML, and the tooling around it is what separates this from a folder of hand-written config files.

There is a `mapvalidator/` directory, a `pyproject.toml` for a package named `atak-maps-validator` at version 0.1.0, requiring Python 3.10 or newer with a single runtime dependency, `requests`. The dev extras add pytest, pytest-cov and responses, and the docs extras add mkdocs-material and qrcode with pillow, which is the library that generates the QR images.

The pytest configuration is strict in a way that matters. The test paths are the `tests` directory, the default options include coverage reporting for the `mapvalidator` package with a term-missing report, the coverage source is set to `mapvalidator`, and the coverage report has `fail_under = 80`. So a change that drops the validator's coverage below 80 percent fails the build, and `show_missing = true` means the report names the uncovered lines rather than just the percentage.

There is a `schema/` directory, which is presumably what the validator checks the XML against, and a GitHub Actions workflow named `validate-maps.yml` with a badge in the README reading XML validation. That is the mechanism that catches a malformed or non-conforming MOBAC file before it reaches a user who is in a field with a dead map.

The rest of the tooling is standard Python: black with a line length of 88, isort with the black profile, and a `uv.lock` file, so the Python side uses uv for dependency management. There is also a `descriptions.yml` at the root, which is the obvious place for the human-readable names that the catalogue table shows, and `mkdocs.yml` for the documentation site.

The documentation set includes a Creating Custom Maps quickstart, an XML reference, and an install guide, which means the project supports people adding their own sources rather than only curating existing ones.

The repository layout is the map list

The top-level directory listing is the catalogue in another form, one directory per provider, and it is a useful thing to scan before you plan an installation.

There is a directory for each provider family: `BLM/`, `Bing/`, `ESRI/`, `GRG/`, `Google/`, `NAIP/`, `NaturalResourcesCanada/`, `OrdnanceSurvey/`, `Poland/`, `basemapDE/`, `cycleosm/`, `michelin/`, `mtbmapcz/`, `openseamap/`, `opentopo/` and `usgs/`. The naming follows the provider column of the generated table, and the `GRG/` directory corresponds to the entries whose provider is GRG, which covers items such as the BC Wildfire fire perimeters, the FEMA National Flood Hazard Layer flood hazard zones, the BLM public lands overlay and the WaymarkedTrails cycle routes overlay.

The `scripts/` directory holds the generation and release machinery, `tests/` the validator's tests, `docs/` the documentation, `images/` the assets including the logo, and `images/` also holds the screenshots used in the README.

Two files at the root are the ones that will tell you how a release happens. `.releaserc.json` configures semantic release, and the publishing instructions are unusually simple: to publish a new version, push a commit to `master` with a message beginning with `feat:` or `fix:` in the Conventional Commits format. The `Map Release` workflow then handles the rest, and the releases follow a clean version sequence, v1.7.1 in March 2026, v1.8.0 in July 2026 and v1.9.0 in October 2026, with the last push on 2026-10-15.

There is also a `CHANGELOG.md`, a `SECURITY.md`, a `CLAUDE.md` and a `CONTRIBUTING.md`.

Where ATAK-Maps is the wrong answer

The first case is a deployment that needs imagery guaranteed offline. Every entry in this collection is a pointer to an online source, and the caching is something ATAK does on request, with the region and the quality you pick. That is genuinely useful and it is not the same thing as shipping the tiles with your unit, and for a team operating beyond reliable coverage it is the wrong tool.

The second case is a user who needs one specific layer, well configured, and nothing else. A single MOBAC XML file is a small amount of text, and the project itself documents how to write your own in the Creating Custom Maps quickstart with a full XML reference. Curating 40 sources is valuable when you want a menu of options; for one source in a controlled environment it is more configuration to remove than to write.

The third case is anyone who needs a guarantee about provider terms. The collection includes Google and Bing layers, and the project itself flags the sharpest issue with OpenStreetMap, noting that OpenStreetMap may restrict ATAK client access and that the maps are included for reference while solutions are explored. The honest position is that this repository lists what is reachable, not what is contractually permitted, and the difference matters if your use is anything other than personal reference.

There is one more practical point about the tap-to-install flow. It depends on the `tak://` scheme added in ATAK 5.1 and on the device being able to reach the catalog site, and the QR code points at a hosted ZIP. For a unit on a restricted network, the manual ZIP import is the path, which means you have to fetch the file some other way and side-load it.

Editorial conclusion

ATAK-Maps fits an ATAK user who needs satellite, topographic or overlay imagery in the field and cannot spend an evening hand-configuring tile sources, and it fits a maintainer who wants a machine-checked catalogue rather than a wiki page. It does not fit a deployment that needs offline imagery guaranteed, because every entry in it points at an online source and the caching still has to be arranged. Before you rely on a particular layer, check its zoom range in the generated catalogue, and note that the collection warns that OpenStreetMap may restrict ATAK client access.

Frequently asked questions

Official sources

1. Issues
2. joshuafuller/ATAK-Maps on GitHub
3. License: MIT
4. README
5. Releases