Use with MILSTD 2525 D?

[kjellmf]

Do you have any plans for supporting the latest 2525 D-revision? One major difference between C and D is the new 20 digit numeric symbol identification code.

[michael-spinelli]

It's something I would like to do. But there are no plans to implement it anytime soon unless I get funded by work to do so. Fortunately, most groups I know are only just beginning to use C and that's been out for years.

https://groups.google.com/forum/#!forum/mission-command-milstd-renderer

[kjellmf]

I understand. The 2525 D-revision is only a couple of months old, so there are probably very few systems that use the D-revision. The new symbol identification code system is more flexible, but it is harder to remember numerical codes than the old character codes.

[michael-spinelli]

No real change but there is potential for funding maybe in the next year. No promises.

https://groups.google.com/forum/#!topic/mission-command-milstd-renderer/y2UZnxNRRwY

[michael-spinelli]

Hey,

You've been looking at ESRI's SVG files, right?

I know symbols like action point have modifiers (H, H1, etc...) built into the SVG file.

I haven't seen an equivalent for any of the other symbology like warfighting. Am I not looking in the correct place or does it not exist?

Thanks,
Mike Spinelli

-----Original Message-----
From: Kjell Magne Fauske [mailto:[email protected]]
Sent: Monday, October 13, 2014 4:23 PM
To: missioncommand/mil-sym-js
Cc: Michael Spinelli
Subject: Re: [mil-sym-js] Use with MILSTD 2525 D? (#3)

I understand. The 2525 D-revision is only a couple of months old, so there are probably very few systems that use the D-revision. The new symbol identification code system is more flexible, but it is harder to remember numerical codes than the old character codes.

—
Reply to this email directly or view it on GitHub blockedhttps://github.com//issues/3#issuecomment-58949123 . https://github.com/notifications/beacon/5972575__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyODg1MDk1OSwiZGF0YSI6eyJpZCI6NDU1MDY2NDR9fQ==--8d117993f540e802c7100816166cb56a6b0718bb.gif

This message contained javascript that has been removed by AKO/DKO in accordance with INFOCON levels 3 and 4.

[kjellmf]

The JMSML SVG files are the same SVGs that they have used to create the official MILSTD2525D document. Some of the SVGs contain some sort of meta data, but only a few. If you for instance open the Main Attack control measure you'll find some hidden groups in the file that are visible in the documentation. You'll recognize the amplifiers, but only as text: https://raw.githubusercontent.com/Esri/joint-military-symbology-xml/master/svg/MIL_STD_2525D_Symbols/Appendices/ControlMeasures/25151403.svg

The idea behind JMSML is to have this kind of information in the schema. For land units you'll can extract the amplifiers (including position) in jmsml_D-Base.xml. For control measures this information is unfortunately missing (https://github.com/Esri/joint-military-symbology-xml/blob/master/instance/jmsml_D_Base.xml#L597). I know that they have plans for adding more metadata about control measures (Esri/joint-military-symbology-xml#174), but until then you have to extract this information from the SVGs (if possible) or manually from the PDF

[michael-spinelli]

Well I can see how control measures aren't in the base xml since positions vary for most of those symbols. It makes sense that the label positions are stored in each symbol SVG that has labels. It's not like the other graphics where they can say here are the modifier positions for all land graphics or here are the label positions for all air graphics.

[Reeter35]

(respawning this enhancement thread)
Was there any changes in the roadmap/funding to get the 2525D?

[michael-spinelli]

No, currently there isn't an Army project (that I'm aware of) with a 2525D requirement. So I haven't been able to convince management that it's worth working on. There's some prototype work in the renderer for 2525D multipoints. But it's disabled, unsupported, untested, and nothing in the SymbolDef table for these symbols. I was thinking of enabling it to drum up interested but I haven't had the time. All development under github.com/missioncommand has stalled for the moment. If you'd like to see that change, complain to your favorite government POC :)

[ComBatVision]

Hi, @michael-spinelli
Any news about AAP6D/mil-std-2525d support?
Latest MIP 4.3 standard was released with bindings only to "D" standard and they do not plan to provide C mappings.
It is a huge problem for my project now.
Your library is the only available for JS, Java and Android. Spatial Illusions support APP6-D, but it exists only for JS.

[michael-spinelli]

It hasn't been a priority for those that would give me funding to do so.
Is there a timeframe for implementation of the MIP 4.3 standard?

[ComBatVision]

Standard itself will be applied in several years, but it should be implemented until then.
I just try to figure out if we have yet another huge task to implement own D support, or may be you plan to do this at least during year.

Could you ask your investors what they think about mip 4.3 support in their project?

[michael-spinelli]

I'm asking around to see if they've considered this.

[michael-spinelli]

Sounds like we're waiting for 2525E which might be around early next year.

[ComBatVision]

It is also a good news, because next MIP release probably will use E.

[michael-spinelli]

OK, follow up. I'm not expecting to get any funding internally for further renderer development to support 2525D/E.
That said, it's not impossible that another party might fund the work. That's how the Android port got developed. But I also wouldn't assume that would happen. I believe all the ports do have 2525D multipoint support buried in there that my fellow developer worked on as there was a lot of overlap with 2525C. It's extensive but I'm not sure if it's complete. Single Point graphics aren't in any of the ports but I'll probably post the code for the 2525D plugin prototype for singlepoints that I worked on for the Java Port at some point.