Military symbology has been a part of the Luciad Portfolio for many years.
It started as a MIL-STD 2525b component in a product called LuciadMap, but quickly grew to include several incarnations of the MIL-STD 2525 and APP-6 standards, amounting to more than 10,000 supported symbols.
Military symbols are points, lines, polygon, ellipses, and much more elaborate geometries, from “L,” “U,” and “T” shapes, to the multi-arcband range fans symbol.
This geometry is paired with dynamic styling rules that depend on the run-time properties of the symbol, resulting in complex line strokes, fill styles, and labels.
The specifications cover thousands of pages. They can be ambiguous, counterintuitive, but never wrong (…even if they are). Let’s also not forget the numerous customization requests from our users that go beyond the specification.
To implement and maintain support for this symbology consistently across the four products and six technologies* that now make up the Luciad Portfolio takes things to a whole other level. So how do we do it?
The Dawn of the Luciad Portfolio
Back in 2012, the flagship product LuciadMap was about to get some siblings: we were implementing the hardware accelerated LuciadLightspeed, and also working hard on LuciadMobile and LuciadRIA.
All products demanded military symbology support, so it was time to do some strategic thinking. After consulting with several product experts, we came up with a plan: to accelerate military symbology development with an order of magnitude.
Military symbology in LuciadMap in 2004
The Plan
The first step was to completely revamp the foundations of the LuciadMap symbology (without any API incompatibilities), making it ready to use in our other products.
Bit by bit, we consolidated fragmented knowledge into comprehensive hierarchy resources. We encapsulated drawing code into icon building blocks. And we designed a declarative styling language that was specifically suited to military symbology.
Every line of code that we could remove was a line we didn’t have to port.
The second step was to make the remaining symbology code as portable as possible.
If we couldn’t share or cross-compile it, we would at least want to see similarities and differences at a glance when putting the code side by side. This required separating visualisation capabilities from styling code and devising a concise, portable API to construct the symbol geometry and its styling.
A third cornerstone was to provide the same styling capabilities on all platforms. The added benefit of this was that military symbology was driving our visualization capabilities forward across our products.
The Benefits
This all worked out seamlessly. There was of course a lot of refactoring, bug fixing, and polishing, but the system worked. Adding cross-product support for a new symbol usually only required adjusting some resource files.
Code changes have become much less common, but if needed, the functionality is easy to locate. A JavaScript developer can easily track down an issue in our Java products, and vice versa. It really boosts the shared responsibility concept.
Needless to say, all this benefits the customer enormously: analysis of a problem only needs to happen in one product. Fixes and improvements can be rolled out quickly to all products. And we can support new symbols and standards much faster than before.
If you’d like to learn more about how military symbology support in the Luciad Portfolio came to be what it is today and how it benefits end users, stay turned for our upcoming blog!
In the meantime, you can learn more about the specific NATO standards-based military symbology capabilities in the Luciad Portfolio.
(*) LuciadLightspeed SW, LuciadLightspeed HW, LuciadRIA SW, LuciadRIA HW, LuciadMobile, and LuciadCPillar
