ATAK data package management: distributing maps and missions at scale

A common operating picture is only as good as the substrate it is drawn on. The live track of a vehicle means little if the operator is looking at a base map that ends at last month's boundary, or if the no-fire areas on one team's screen differ from another's. In the TAK ecosystem, the unit that distributes that substrate – maps, overlays, imagery, points of interest, and mission graphics – is the data package. This article examines how data packages are structured, versioned, published, and synchronized across a tactical network, and why the bandwidth strategy you choose for them matters as much as the content itself.

What a data package is, and what it is not

An ATAK data package is a ZIP archive with a defined internal layout. At its root sits a manifest – MANIFEST/manifest.xml – that assigns the package a UID and a human-readable name and enumerates every file the archive contains, each with its relative path inside the ZIP. The remaining contents are the payload: KML or KMZ overlays, map-source descriptors, imagery and offline tile sets, point-of-interest lists, plugin configuration, and free-form mission documents such as briefing PDFs.

When ATAK imports the archive, it reads the manifest first, then unpacks each listed file into the correct ATAK directory – overlays into the overlay store, map sources into the map-source registry, tiles into the map cache – and registers the content so it appears on the map immediately. The manifest is the contract: a file present in the ZIP but absent from the manifest is ignored, and a file listed in the manifest but missing from the ZIP is an import error. Authoring discipline starts there.

It is worth being precise about what a data package is not. It is not the live picture. Cursor on Target (CoT) events are small, ephemeral XML messages – a position report, a marker, an alert – that stream continuously and expire on a stale timer. A data package is large, durable reference content that changes rarely and is distributed deliberately. CoT is what is moving; the data package is the world it moves through. Conflating the two is the root of most distribution mistakes: teams try to push map-sized content through the CoT path, or treat a mission graphic as if it were a transient event. They belong on different transports with different bandwidth budgets.

Anatomy of the manifest

The manifest carries three things that matter operationally. The UID uniquely identifies the package across the network, so two teams referring to "the boundary overlay" are provably referring to the same artifact. The name is what operators see in the import dialog and the package list. The content list drives unpacking. Disciplined teams treat the name as a versioning surface – embedding a semantic version and a published date, for example fires-overlay_v4_2026-06-11 – because the name is the only human-readable handle an operator has when deciding whether the package on their device is current.

Versioning by content hash

Underneath the human-readable name, data packages are versioned by content hash. Any change to any contained file – a moved point, a re-rendered tile, an edited briefing – produces a different archive and therefore a different hash. TAK Server keys packages by that hash, and tracks the current hash for each named package. This gives the network an unambiguous answer to the only question that matters during sync: does the client hold the same bytes the server considers current?

The practical consequence is that versioning is not optional metadata – it is the synchronization mechanism. When a client reconnects after a disconnected period, it compares the hash of its local copy against the server's current hash. A match means no transfer is needed; a mismatch triggers a download. This is why embedding a visible version in the manifest name and keeping a release register (version, hash, one-line changelog) is more than housekeeping: it lets a human reconcile what the hash comparison decides automatically, which is essential when an operator in the field reports that "the overlay looks wrong" and you need to determine which revision they are actually holding.

Distribution paths: TAK server, missions, and direct transfer

There are three ways a data package reaches an operator, and a mature deployment uses all three for different content.

TAK Server Enterprise Sync. The primary path. A client uploads a package to the server's file store over the authenticated HTTPS API; the server stores it keyed by hash and exposes it for download. Other clients pull it on demand. This is the path that scales, because the server – not a person – handles storage, deduplication, and access control.

Missions. A Mission is a server-managed collection of content and CoT scoped to a named operation. Clients subscribe to a Mission, and the server auto-pushes the Mission's data packages to every subscriber and notifies them when a package changes. This converts distribution from a pull-when-you-remember model into a push-on-change model, which is what makes large user counts manageable. When a fires overlay updates, the operator does not go looking for it – it arrives, and only the changed package transfers. Scoping Missions tightly to the units that need them also keeps distribution audit-friendly and prevents content sprawl. Federating Missions across separate networks is itself a discipline; see our note on connecting multiple TAK networks across units and commands.

Direct and offline transfer. Peer-to-peer transfer between two ATAK clients over a local link, or sideload from physical media, covers two cases the server cannot: the initial bulk load of multi-gigabyte base maps before deployment, and disconnected operations where there is no server reachable. The cost is that these transfers fall outside the server's hash tracking, so the visible version in the manifest name becomes the only reconciliation aid.

Bandwidth strategy: splitting content by volatility

The single most important design decision in data-package management is how you partition content, and the correct axis is volatility – how often a piece of content changes – not subject matter. Static, heavy content and dynamic, light content have opposite distribution profiles and must never share an archive.

Base maps and imagery are large and almost never change within an operation. A regional offline tile set can run to several gigabytes. This content should be packaged on its own and distributed by physical media or local Wi-Fi during the staging phase, before any team is on a constrained link. The bandwidth math is decisive: pushing a 4 GB map set over a 50 kbps tactical radio link is not slow, it is operationally impossible, and attempting it will saturate the channel and starve the live CoT picture for hours.

Mission overlays, points of interest, and graphics are small – often kilobytes – and change frequently. This is the content that belongs on the network path, because it must stay current and the volume is trivial. The discipline of separating these two classes means an operator who needs a one-line edit to a boundary overlay downloads a few kilobytes, not a re-bundled multi-gigabyte archive. The same offline-packaging concerns apply to the maps themselves; our guide to MBTiles and PMTiles for tactical applications covers how to build those base layers efficiently in the first place.

Delta transfer and rate limiting

Even with content split correctly, a package occasionally must traverse a constrained link – a base-map correction discovered mid-operation, for instance. Two techniques keep that survivable. Delta transfer moves only the difference between the client's current revision and the new one, rather than the whole archive; for a tile set where a handful of tiles changed, this can reduce a multi-gigabyte transfer to a few megabytes. Rate limiting caps the bandwidth a package transfer may consume so it can never starve live traffic, and scheduling the transfer outside peak operational windows further protects the picture. The governing rule, regardless of mechanism, is absolute: reference-data transfer must never compete with the live common operating picture.

Operational pitfalls and how to avoid them

The monolithic package. The most common anti-pattern is one giant package containing everything – maps, imagery, overlays, documents – re-published whenever any single element changes. Every change forces every subscriber to re-download the whole thing. The fix is volatility-based partitioning, applied from the start.

The orphaned sideload. A package handed device-to-device during an operation never enters the server's hash tracking, so the network has no record of who holds what revision. When the operation reconnects, those devices may not reconcile against the server copy and quietly retain a stale overlay. The mitigation is a visible version in the manifest name plus a deliberate post-reconnection reconciliation step.

The unscoped Mission. A Mission everyone subscribes to becomes a dumping ground; packages accumulate, irrelevant content pushes to devices that do not need it, and the audit trail blurs. Scope Missions to operational need and prune retired content. This kind of housekeeping is part of the broader operational hygiene covered in TAK fleet and device management practice.

The untested device class. A package that renders correctly on a development tablet may fail on a low-storage rugged handset, or a map source may reference a tile layout the field device does not support. Always verify a new package on a representative device of each class in the fleet before publishing it to the Mission, and confirm during that check that the live CoT picture was not degraded while the package transferred.

Putting it together: a distribution workflow that scales

The techniques above combine into a repeatable workflow. Before deployment, build the heavy base-map and imagery packages and load them onto every device by physical media – this is the one-time bulk cost, paid once where bandwidth is free. During the operation, every volatile artifact – boundary overlays, fire support coordination measures, points of interest, route graphics – lives in small, hash-versioned packages attached to a tightly scoped Mission on TAK Server. When an overlay changes, the author re-publishes the single affected package; the server computes the new hash, notifies subscribers, and each device pulls a few kilobytes. Disconnected elements reconcile on reconnect by hash comparison, and any sideloaded copy carries a visible version in its name so a split is detectable by eye.

The result is a network where the substrate stays current without a human ever shuttling files, where a one-line edit costs kilobytes rather than gigabytes, and where reference-data transfer is structurally incapable of starving the live picture. That last property is the real measure of a sound data-package strategy: not that content arrives, but that it arrives without ever displacing the tracks an operator is actually trying to read. A distribution scheme that delivers a perfect map at the cost of a stale common operating picture has failed at exactly the moment it matters most.