Symbology rendering in TAK: MIL-STD-2525 on mobile maps

A military map is only as useful as the symbols on it. When a TAK operator glances at a handheld screen in poor light, the shape, color, and fill of each icon must communicate affiliation, type, echelon, and status in a fraction of a second – and they must match what the command post sees on its wall display. That correspondence is what MIL-STD-2525 exists to guarantee, and rendering it correctly on a constrained mobile device is a deceptively hard engineering problem. This article examines how TAK clients turn a compact symbol code into a pixel-perfect, performant icon: the symbol identification code, milsymbol-style generation, the caching strategies that keep frame rates high at scale, custom iconsets, and the discipline required to stay consistent with the broader C2 picture.

The symbol identification code: the data contract

Everything in TAK symbology begins with the symbol identification code, the SIDC. The SIDC is a short standardized string that uniquely names a military symbol – its affiliation (friendly, hostile, neutral, unknown), its battle dimension (ground, air, sea surface, subsurface, space), its status (present or anticipated), and its specific entity within the symbol set. In MIL-STD-2525C the SIDC is a 15-character alphanumeric string; in MIL-STD-2525D and the closely aligned NATO APP-6(D) symbol set it is a 20-character numeric code organized into a digit-pair structure.

The SIDC is the contract between every system in the picture. A C2 server, a fixed-site dashboard, and a handheld TAK client that all agree on a SIDC will render the same symbol – same frame shape, same fill color, same icon glyph. This is why the SIDC, not a pre-rendered image, is what travels across the network. Shipping a bitmap would freeze the symbol at one size, one theme, and one client's interpretation; shipping the code lets every endpoint render natively at its own resolution and density. Symbology engineering done well at the dashboard level – the subject of our companion piece on MIL-STD-2525 in practice – is the same discipline applied at the other end of the wire.

How TAK carries the SIDC over cursor on target

TAK does not transmit a raw SIDC field on every event by default. Instead, Cursor on Target (CoT) encodes affiliation and battle dimension in the event type attribute – a dotted hierarchical string such as a-f-G-U-C-I for a friendly ground infantry unit. The leading a marks an atom (a real-world object), the second token is the affiliation, and the remaining tokens descend the 2525 hierarchy. A renderer maps this CoT type to a canonical SIDC before generation.

Where a richer symbol is needed – full 2525D fidelity, echelon modifiers, or specific entity subtypes – the producing system adds a detail extension to the CoT event carrying the explicit 20-character code. The TAK client reads the extension when present and falls back to deriving the code from the CoT type when it is absent. The practical lesson for integrators is to never assume the SIDC arrived as a clean field: build a normalization step that produces one canonical code from whatever the event happens to contain.

Generating the glyph: milsymbol-style rendering

Once a canonical SIDC is in hand, the client must turn it into pixels. The dominant approach in the TAK ecosystem and in web-based C2 clients is a symbology engine that takes a SIDC plus a set of modifiers and emits a vector symbol – the milsymbol library is the best-known open implementation of this model, and several TAK renderers follow the same architecture even when they use a different code base.

The engine composes the symbol from layered primitives: the frame (the outer shape encoding affiliation – a rectangle for friendly, a diamond for hostile, a square-cornered shape for neutral, a quatrefoil for unknown), the fill color, the central icon glyph identifying the entity type, and a ring of optional text and graphic modifiers – echelon ticks above the frame, a staff or mobility indicator below, status dashing for anticipated entities, and free-text fields such as unique designation or higher formation. The output is typically an SVG, because vector output scales cleanly across the wide range of pixel densities found on tactical Android hardware.

From SVG to a map marker

A live map cannot afford to re-parse and re-rasterize an SVG on every frame. The standard pipeline rasterizes the generated SVG exactly once, at the target device-pixel size, producing a bitmap that the map engine treats as an immutable marker image. The bitmap is anchored at the symbol's hot point – the geometric center of the frame, not the bottom edge as with a teardrop pin – so the icon sits precisely over the entity's geolocation. Getting the anchor wrong is a common and subtle bug: a symbol offset by half its height looks fine when stationary and visibly lags the truth when the entity moves.

Performance at scale: the cache is the architecture

Generating a MIL-STD-2525 glyph is computationally expensive – it walks the symbol set, composes several layers, lays out text modifiers, and rasterizes vector paths. On a mid-range rugged Android device, generating a few hundred unique symbols at startup is noticeable; regenerating them on every map pan would make the client unusable. The single most important architectural decision in mobile symbology rendering is therefore the cache.

The cache key is the canonical SIDC combined with the render size and any modifiers that change the pixels (echelon, status, direction-of-movement indicator). Two markers that share a key share a single bitmap. In a realistic tactical picture the number of distinct symbols is far smaller than the number of entities: fifty friendly infantry markers all resolve to one cached glyph. A well-tuned client sees cache hit rates well above ninety percent during normal operation, which means symbology generation cost is paid once and amortized across the whole session.

Three further techniques keep the render loop within frame budget. First, pre-render the most common frames – friendly and hostile ground and air symbols – at application startup so the first map draw never stalls. Second, decluster and decimate at low zoom: when hundreds of markers collapse into a few screen pixels, drawing them all is wasted work, so collapse dense formations into a single representative symbol or a count badge. Third, render at fixed device-pixel sizes and let the map engine scale within a zoom band rather than regenerating bitmaps as the user pinches. These map-engine concerns mirror the broader rendering trade-offs discussed in our note on real-time map rendering for military C2.

Custom icons and non-standard entities

Not every object on a tactical map has a clean MIL-STD-2525 representation. A specific UAV airframe, a named civilian asset, a piece of engineering equipment, or a unit-specific marker may need a bespoke glyph. TAK supports this through custom iconsets – packaged collections of bitmap icons referenced by a relative path carried in the CoT detail. The client loads the iconset, resolves the path, and places the bitmap as it would any other marker image.

Custom icons buy presentation flexibility at a real cost: a bitmap path carries no structured meaning. A 2525 SIDC tells any consuming system that an entity is hostile, airborne, and anticipated; a path to custom/quadcopter.png tells it nothing machine-readable. The disciplined pattern is to keep a valid SIDC underneath the custom presentation – encode affiliation and dimension in the CoT type even when a custom icon is displayed – so that filtering, alerting, and cross-system reasoning still work. The custom icon is then a cosmetic override on top of a machine-readable foundation, not a replacement for it.

Consistency with the C2 picture

The hardest symbology problems are rarely about a single client; they are about agreement across many. An operator on a handheld and a watch officer at a command post must see the same affiliation, the same frame, and the same echelon for the same entity – divergence here is not a cosmetic flaw but a potential fratricide risk. Consistency rests on two rules.

First, set the authoritative SIDC once, at the source, and never re-derive it locally. If a forward observer's app and the C2 server each independently guess at affiliation from incomplete data, they will eventually disagree. The producing system owns the code; every downstream renderer treats it as immutable input.

Second, render from a common standard edition. A client implementing MIL-STD-2525C and a server implementing 2525D can produce subtly different frames and fills for the same conceptual entity because the symbol sets evolved between editions. When a deployment must mix editions – which is common, since fielded hardware lags standards – insert a translation layer that maps SIDCs between editions deterministically. The translation table, not ad-hoc per-client logic, becomes the single place where edition differences are reconciled, so an operator never sees a hostile diamond where the command post shows a friendly rectangle.

Offline operation adds one more constraint: the full symbol set and any custom iconsets must be preloaded to the device, because a TAK client in a denied-comms environment cannot fetch a missing glyph on demand. Symbology assets travel with the offline map package, alongside the tile data covered in our guide to packaging offline maps for tactical applications.

Putting it together

A robust mobile symbology pipeline is therefore a short, disciplined sequence: normalize whatever the CoT event carries into one canonical SIDC, check a SIDC-plus-size cache before doing any work, generate from a milsymbol-style engine only on a miss, rasterize once and anchor at the hot point, cluster intelligently at low zoom, and reconcile editions against the C2 picture through a single translation layer. Each step is simple in isolation; the value is in applying all of them consistently so that a thousand-entity battlefield renders instantly and reads identically from the handheld to the command post.