2525D Legacy Mapping Issues

[Dbarnes1]

Issues with table provided at: https://github.com/Esri/joint-military-symbology-xml/blob/master/samples/legacy_support/All_ID_Mapping_C_to_D.csv

Current Issues

Name	Key 2525C	Main Icon	Notes/Corrective Action	Workaround Available?	Fixed?
Friend: Land Unit (SIGINT)	IFGP-	0_310_0	Change Unit Frame from: 0_310_0 --> Equipment: 0_315_0		Yes - #264
Friend : Land Unit (SIGINT)	IFGA-	0_310_1	Change Unit Frame: 0_310_0 --> Equipment: 0_315_1		Yes - #264
Many Sustainment/SUPPLY Symbol (one example here)	S-G-USSL--		Missing "SUPPLY" Horizontal Bar	2525D doesn't use those horizontal bars so fix is with a LegacyEntity and new SVG
No MOOTW Echelon Indicators	Ex: O****------A---	O-	Echelon Indicators missing for MOOTW/SASO (Appendix E)		Yes - #277
No MOOTW FD/TF Indicators	Ex: O****-----F----	O**--F	FD/TF Indicators missing for MOOTW/SASO (Appendix E)		Yes - #277
Repeated Key2525Cs (non METOC)	Ex: S-A-WM----, S-G-IMC---, S-G-UUMSEC, S-G-UUMSET, G-G-DAB---, G-G-GLF---, E-O-A-----, S-G-UCAAAS		I know we discussed that a few (~8) METOC codes with the same function code would be repeated, but I wasn't expecting the others		Yes - #263
METOC Weather	Ex. W---OBVA--		Missing D in all Dynamic Weather SIDCs	The decision was to disregard the fourth character in all SIDCs for the purposes of building the key values, thus the dash (-) is used in ALL cases as a place holder. Putting a D here breaks the consistency of this approach and isn't needed to uniquely identify a weather symbol
Emergency Op Team	E-O-BJ----		Team echelon amplifier placement is wrong		Yes - #277
"I" "J" Used in Icons	several		Showing up in Serif Font		Yes - Switch from Inkscape 0.91 to 0.48
Aviation Rotary Wing Confusion	S-G-UCVRS and S-G-UCRVO		Confusion in LegacySymbols/LegacyEntities

Future Issues to Check

Name	Key 2525C	Main Icon	Notes/Corrective Action	Workaround Available?	Fixed?
Stability Operations (So), Items, Refugees	O-I-R-----	11110400	Substitute Icon - Not sure what the issue here is, If the problem is that the icon looks different from the original then the answer is to create a new LegacyEntity and SVG for the original icon.

• some originally from table _Corrections_To_JMSML_Produced_Mapping_C_toD

[Dbarnes1]

@csmoore could you write some sort of explanatory text above the table so that this is more easily understood? I replicated the table but I think you can clarify this issue for when we get around to fixing these.

[csmoore]

Let me know if you need clarification on any others, but here are some screenshot of some of the issues encountered:

(2525C foreground/transparent - 2525DtoLegacy Background/opaque)

Change SIGINT Unit Frame from: Land to Equipment:

Missing "SUPPLY" Horizontal Bar:

Repeated 2525C SIDCs:

[abouffard]

I have evaluated each of the repeated key values and here are my findings:

Key	Explanation
S-A-WM----	Oversight in JMSML. Redundant entry will be deleted
E-O-A-----	Oversight in JMSML. Redundant entry will be deleted
S-G-IMC---	DISA's mapping xls file maps two 2525D symbols to one 2525C symbol. JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC
S-G-UUMSEC	DISA's mapping xls file maps two 2525D symbols to one 2525C symbol. JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC
S-G-UUMSET	DISA's mapping xls file maps two 2525D symbols to one 2525C symbol. JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC
S-G-UCAAAS	DISA's mapping xls is ambiguous, listing this as mapped AND retired. I have contacted DISA for which is the correct choice
G-G-DAB---	A CP removing redundant control measures will fix this, when implemented
G-G-GLF---	A CP removing redundant control measures will fix this, when implemented

[csmoore]

@abouffard - you can retain the 2-1 mapping as needed but please note that both shouldn't appear in the 2525C legacy mapping table

[abouffard]

E-O-BJ---- needs to be fixed so the team amplifier is included as a separate part of its legacy mapping entry.

https://cloud.githubusercontent.com/assets/3090809/13637488/9884e7f8-e5d5-11e5-82bf-719175b02fb6.png

[abouffard]

All of the redundant/repeated keys listed above have now been dealt with. There should now be only one of each of those keys in the legacy mapping table.

Fixed this in the CSVs merged in #263

[abouffard]

@csmoore , the SIGINT frames need to be changed from land unit to land equipment in the renderer plugin. All SIDCs starting with "I-G-" need to be handled in this way. Where/how do you want to track plugin issues, since this is not a JMSML issue?

[csmoore]

@abouffard - confused - if this is the frame mapping for "I-G-" - why is this an issue with the plugin and why does it not appear in the Mapping Table this way? I.e. why is it not handled like every other frame case mapping?

[csmoore]

@abouffard - for the "E-O-BJ----" issue mentioned in the comments - please add that to the original issue description above (we find that people don't always read through the individual comments/thread to pick out additional issues like this - especially when the comments get this lengthy - but they do read the 1st issue)

[csmoore]

@abouffard - checking back on SIGINT frame issue - do you think this should be fixed in the data table or plugin?

[abouffard]

@csmoore - it has been fixed in the table. My bad for suggesting otherwise, that it was a plugin issue. I was thinking along a different line when I suggested it was a plugin problem. The legacy stylx I created last night should have SIGINT now drawing in equipment frames. I'll be putting those JMSML corrections into GitHub tonight.

[csmoore]

@abouffard - for the Sustainment/SUPPLY Symbol Bar issue noted above - rather than create completely new symbols - would it be possible to just add the "Bar" Icon to the "ExtraIcon" field in the mapping table - cases like this is what that field/column was intended for.

[abouffard]

@csmoore, it would be one solution, but as the mapping table is being generated from JMSML and JMSML has a consistent way to handle icons that are unique to the legacy standards, this would be an inelegant exception. Since the bar is full frame we'll both have to also contend with there being four versions of the situation, whether it's four versions of a lone ExtraIcon bar or four versions of the complete barred supply icon.

It bothers me as it is that I need to handle the team amplifier on E-O-BJ as an exception, unless we also make that symbol four separate complete icons.

[csmoore]

Added to the original issue to investigate why some of the fonts are now showing as serif:

@abouffard - regarding last supply bar comment- we already handle both this full frame case and the case where a single additional icon in needed with the "special land unit entity" icons (in the "ExtraIcon" field) so I am not sure why the supply bar would be any different or less "elegant"

[abouffard]

@csmoore , the "special land unit entity" is an exception whose alternative (creating many new SVGs that include those extra icons and the standard land unit icons together) would seriously bloat the number of SVGs in the mix. Thus using the "ExtraIcon" approach is warranted in that case.

The "special land unit entity" icons have also already been removed from 2525D Change 1, in favor of new sector modifiers to convey the same information, so using "ExtraIcon" here as a temporary and, in my opinion, inelegant workaround is again warranted.

When we do implement the CP that removes these "special land unit entity" icons, I'd prefer to see the "ExtraIcon" concept go away completely, which could only happen if we minimize reliance on it.

[csmoore]

I was also thinking this affected every supply icon - but on visual inspection, it looks like only the 2525C water and laundry are affected anyway (so only an extra ~10 icon):

But had we been aware of your temporary/for-special-land-unit-only intention when we developed/reviewed the legacy table - we might have taken another approach or at least named this column better.

What is the CP number for the D Change 1 mentioned? I am curious where this new/proposed modifier is going to fit into the current 20-char scheme.

[abouffard]

It's part of a recently approved CP (16-010-AR). @joebayles and I will be issuing a SSMC/JSP 16-1 trip report soon, and moving the recently approved CPs to Box, and as part of our engagement with the SSMC/JSP, JMSML.

16-010-AR Modify MIL-STD-2525D to Support Updates to Army Doctrinal Symbology.docx

[csmoore]

Thanks for providing the CP here (funnily enough it also covered changing the supply bar to a modifier which would have helped with the issue above) - that does look like an improvement & I will be happy to see the "special entity subtype" exceptional case/rule go away.

[abouffard]

Yes, although I argued against it as it creates another exception. A full frame sector one modifier.

[csmoore]

I guess I don't understand the exception in this case, the new/proposed (full frame) Supply Bar and Headquarters Element modifier 1's are icons that are tagged as full frame, so follow the normal full frame lookup rules.

But if it is somehow an exception (presumably because these are the only full-frame modifiers), then it is certainly the lesser of two evils

[abouffard]

It's just that. That the established rule for modifiers is that they are supposed to fit wholly within a sector., to ensure consistency and readability. This becomes the lone exception, and I always counsel the committees to minimize exceptions.

[abouffard]

Removed the list of missing symbols that need investigating and put them in a new issue #289

[joebayles]

Closing per @Dbarnes1