Comments (18)
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"?
from joint-military-symbology-xml.
For now, might be best to just get started by getting:
- The graphics included in the icon exports -and-
- 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
from joint-military-symbology-xml.
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
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
@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.
from joint-military-symbology-xml.
Added FULL_FRAME icons to export in #74
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
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
from joint-military-symbology-xml.
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"
from joint-military-symbology-xml.
Will be updating OneNote today.
from joint-military-symbology-xml.
@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?
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
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.
from joint-military-symbology-xml.
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
from joint-military-symbology-xml.
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):
- Look up the tags for item, if "FULL_FRAME" Central Icon should be normal SSEEEEEE icon with
- Select alternate icon based on identity/affiliation:
- _0 should be used with Pending and Unknown frames (standard identity codes 0 and 1).
- _1 should be used with Assumed Friend and Friend frames (standard identity codes 2 and 3).
- _2 should be used with Neutral frames (standard identity code 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 :
- Lookup using the expected key: 10111000
- Opps - that doesn't work - it must be a "Full_Frame" one, apply "select alternate icon" rule from above
- 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.
from joint-military-symbology-xml.
Your logic for starting backwards from the data store only can also be...
using "Command and Control : Signal : Unknown" for example:
- Examine name of item and note the trailing token is one of "Unknown", "Friend", "Hostile", or "Neutral".
- 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.
from joint-military-symbology-xml.
Related Issues (20)
- 18-011-MC Add Battle Handover Line Control Measure
- 18-012-MC Add Forward Passage of Lines as a Tactical Mission Task
- 18-013-MC Add Rearward Passage of Lines as a Tactical Mission Task
- 18-014-MC Add Control Point Control Measure
- 18-015-AR Add Human Resources Symbology
- 18-011-UK Boundary Amplifier Clarification
- 18-012-UK Lines Amplifiers Clarification
- 18-XXX-UK SCP Approval Clarification
- 18-014-UK Planned Control Measure Symbol ID
- Draw Rules for Antitank Ditch and Wall HOT 6
- Empty Paths in SVGs HOT 1
- Additional Affiliations HOT 1
- Ship Area of Interest - Questions HOT 1
- Variation in SVG size for Control Measures and METOC
- Ambiguity in the wording and examples regarding obstacle color HOT 2
- Trip Wire Draw Rule Disparity HOT 1
- Dismounted Individual Leadership Amplifier HOT 2
- Drawing SVGs and viewbox/crop area HOT 6
- Symbols do not scale as expected
- Update to MIL-STD-2525 revision E
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from joint-military-symbology-xml.