Add remaining Missing icons to the icon exports (ex. FULL_FRAME icons)

[csmoore]

A known issue/already discussed, just adding an issue for tracking/testing.

Currently the only version of the icons exported for FULL_FRAME (center icons that touch the frame) icons are the "_2.svg" (Neutral) version ( Example ).

That was an optimization but now that we are entering the stabilization/refinement stage, it is probably time to address this issue so all of the icons are exported for these.

Some possible derived tasks/things to make sure are included/addressed:

• The Tags need to include some tags that identify this condition: "FULL_FRAME", etc (currently this info is only in the "Notes" columns so should be moved/included with the tags so they are accessible)
• You'll also probably need to append " : Friend" " : Neutral" " : Hostile" " : Unknown" to the icon name to keep unique
• Explain the rules of how we go from the name/tags to assembly a complete symbol for these

[abouffard]

The names need to be unique, but wouldn't the numeric version of the ID also need to be too?

Movement and Maneuver : Infantry,10121100

Needs to become...

Unknown : Movement and Maneuver : Infantry,110121100
Friend : Movement and Maneuver : Infantry,310121100
Neutral : Movement and Maneuver : Infantry,410121100
Hostile : Movement and Maneuver : Infantry,610121100

Where 1, 3, 4, and 6 at the beginning of the number represent the four standard identity variations on full frame icons (the actual standard identity code values from the SIDC - which equate to _0, _1, _2, and _3 in the svg/emf file names).

For domain/value lookup purposes with our symbol renderers, would we need to add one row for each standard identity, even though we only have four full frame icons for each symbol and a couple of the entries below will point to the same svg/emf files, as a result?

Pending : Movement and Maneuver : Infantry,010121100 ----> Uses 10121100_0.svg
Unknown : Movement and Maneuver : Infantry,110121100 ----> Uses 10121100_0.svg
Assumed Friend : Movement and Maneuver : Infantry,210121100 ----> Uses 10121100_1.svg
Friend : Movement and Maneuver : Infantry,310121100 ----> Uses 10121100_1.svg
Neutral : Movement and Maneuver : Infantry,410121100 ----> Uses 10121100_2.svg
Suspect/Joker : Movement and Maneuver : Infantry,510121100 ----> Uses 10121100_3.svg
Hostile/Faker : Movement and Maneuver : Infantry,610121100 ----> Uses 10121100_3.svg

Or can we just have just the four symbol entries and expect our military symbology renderers to have some logic in them that can "map" seven different standard identities on "input" and reduce them to four possible standard identity symbols on "output"?

[csmoore]

For now, might be best to just get started by getting:

1. The graphics included in the icon exports -and-
2. Simple/Straightforward rules for going from name/id to correct icon
   (that preferably doesn't use "renderer" language, just simple english like on the SVG readme page ).

So let's focus on that for the short term. Also, we likely will not need the IDs to be numeric or have them included in the domain exports (so the ids/name can match the current file name convention with _0, _1, etc).

Also, the affiliation/identity might make more sense at the end:
Movement and Maneuver : Infantry : Unknown,10121100_0

[csmoore]

Adding "Land unit icons – special entity subtypes" to the missing icons list that should be added.

HEADQUARTERS ELEMENT - 10xxxx95_X
DIVISION AND BELOW SUPPORT - 10xxxx96_X
CORPS SUPPORT - 10xxxx97_X
THEATER/ECHELONS ABOVE CORPS SUPPORT - - 10xxxx98_X

[csmoore]

I couldn't find boundary lines either :

Command and Control Lines : Boundary : Lateral 110101
Command and Control Lines : Boundary : Forward 110102
Command and Control Lines : Boundary : Rear 110103

But I did find this: https://github.com/Esri/joint-military-symbology-xml/blob/master/instance/jmsml_D_Control_Measure.xml#L21

Not sure what the issue was though.

[abouffard]

@csmoore ( @joebayles ) : Lateral, forward, and rear boundaries are just examples of the use of boundaries. They are not separate different control measures, requiring their own unique SIDCs. The pictures in the standard are there to illustrate how boundaries are used, and that when they are drawn relative to the enemy or each other, they assume an appellation like, "Forward", "Lateral" or "Rear".

UPDATE : I'm now investigating with the SSMC why Mike included SIDCs for Forward, Lateral, and Rear in Appendix A but not in the control measure appendix. Another inconsistency that missed review by members of the SSMC. The Army voting representative for SSMC tells me there is no need for those three extra boundaries.

[abouffard]

Added FULL_FRAME icons to export in #74

[csmoore]

RE: boundaries - someone else could possibly make the opposite case looking at the standard so if we are not implementing can we just capture that explanation/information in some fashion in the the Tags?

For now, we can just include the Change Proposal number with this issue just so it can be tracked.

[mepler]

RE: boundaries - The removal of the SIDC from Appendix H (Control Measures) for the 'Forward', 'Lateral', and 'Rear' boundaries was approved right before the release of MIL-STD-2525D and should not be listed in Appendix A of the document. As a note: Appendix A is just a quick listing of all the symbols/codes within the other appendices and is secondary in terms of the authoritative SIDC. The codes listed within the symbol set appendices take precedence whenever there is a disconnect between the two.

[csmoore]

Thanks I think there was just some additional confusion for this particular one since those exact names/graphics also appeared in Appendix H, so it wasn't clear if the Codes had just been left off the Appendix H version. But explanation sounds good & if possible if we can get a CP or other change tracking number to refer anyone who might question - that will help also.

[abouffard]

Support for these is now in via PR/Merge #80

HEADQUARTERS ELEMENT - 10xxxx95_X
DIVISION AND BELOW SUPPORT - 10xxxx96_X
CORPS SUPPORT - 10xxxx97_X
THEATER/ECHELONS ABOVE CORPS SUPPORT - - 10xxxx98_X

[csmoore]

Looks nearly complete, just need to add the final quick/very brief write-up to "Explain the rules of how we go from the name/tags to assembly a complete symbol for these"

[abouffard]

Will be updating OneNote today.

[csmoore]

@abouffard - a question regarding that (_0, _1, _2, _3) nomenclature/encoding, there seems to be 2 different encodings:

1: "FULL_FRAME" encoding:
Unknown - 0
Friend - 1
Neutral - 2
Hostile - 3

2: Everywhere else:
Unknown - 1
Friend - 3
Neutral - 4
Hostile - 6

Would it be possible to make these consistent (using the 2nd encoding) so there isn't an opportunity to misinterpret these and everything is consistent?

[csmoore]

Nevermind - just realized that is already burned into all the file names (and we want to follow that convention) - perhaps something to consider for next time...

Just make sure you explain that extra mapping step in the verbal explanation of how to derive these.

[abouffard]

That's really a question for DISA, as the svg file naming convention is theirs.

@mepler : can we please have the _0, _1, _2,and _3 svg file names renamed to _1, _3, _4, and _6.respectively? That would make the file names also consistent.

Alternatively, we could leave the files names as they are and just export the IDs using _1, _3, _4, and _6. Do we care if the file names use one naming scheme and our internal unique IDs use another?

** Update ** I just saw @csmoore's "nevermind" and I'd already written this.

Perhaps for Change 1 we can rename the files, and then make the IDs consistent with _1, _3, _4, _6.

[csmoore]

Nevermind, let's keep them as they are for now & you all can evaluate that later - like I said I forgot about the file names (and was just looking at the IDs trying to figure out the breakout) - it is better that the ids/filenames match the existing convention - sorry for the sidetrack

[csmoore]

I am going to close this - although I was still awaiting an explanation of when/how to apply the _1, _2, _3, _4 logic/substitution

But now that the "FULL_FRAME" tag is there, I imagine it is something like this:

If I am starting backwards from the data store only (un-usual/symbol builder/editor case):

1. Look up the tags for item, if "FULL_FRAME" Central Icon should be normal SSEEEEEE icon with
2. Select alternate icon based on identity/affiliation:
   1. _0 should be used with Pending and Unknown frames (standard identity codes 0 and 1).
   2. _1 should be used with Assumed Friend and Friend frames (standard identity codes 2 and 3).
   3. _2 should be used with Neutral frames (standard identity code 4).
   4. _3 should be used with Suspect/Joker and Hostile/Faker frames (standard identity codes 5 and 6).

However this does introduce a complication when going from the SIDC (the usual, normal, messaging case) - because this complication means we can't necessarily use these Unique IDs as lookup keys from the SIDC, because the SIDC doesn't tell you when these "Full_Frame" cases apply. As a concrete example:

Suppose I had Unknown : Land Unit : Command and Control : Signal;( (10, 01, 10, 0, 0, 00), (111000, 00, 00) )

Usually the SIDC is all I need to look up this symbol using the key 10111000 - but now I instead have to :

1. Lookup using the expected key: 10111000
2. Opps - that doesn't work - it must be a "Full_Frame" one, apply "select alternate icon" rule from above
3. Still not there - must be a bad one (after 2 trips to the datastore)

This is OK & no need to respond(unless you want let me know I got something wrong), just trying to capture this for my own benefit.

[abouffard]

Your logic for starting backwards from the data store only can also be...

using "Command and Control : Signal : Unknown" for example:

1. Examine name of item and note the trailing token is one of "Unknown", "Friend", "Hostile", or "Neutral".
2. Select alternate icon based on that value ("Unknown" = _0, "Friend" = _1, "Neutral" = _2, "Hostile" = _3.)

Your second case logic is correct. The SIDC does not encode whether an icon is full frame or not.