APP-6(B) does support some identity and status options for military symbols
topowright-zz opened this issue · 10 comments
Based on the issue following issue:
#218
Using the app6b.stylx in Runtime 100.2 these identity and status options are not honored:
| Example SIDC | Identity/Status/Frame type |
|---|---|
| SFGAUCI-------- | PLANNING/ANTICIPATED (DASHED FRAME OUTLINE) |
| SPGPUCI-------- | PENDING (DOTTED FRAME OUTLINE) |
| SAGPUCI-------- | ASSUMED FRIEND (DOTTED FRAME OUTLINE) |
| SSGPUCI-------- | SUSPECT (DOTTED FRAME OUTLINE) |
We need to be able to support the identity and status options for APP6B that are outlined in the 2525c standards book on pages 15, 16 and 51.
@ACueva @BobBooth @csmoore @dfoll I have not looked thru the APP6 standard, but if you are familiar with those locations in that standard please update or add that information to this issue.
@topowright - here is the APP-06(B) affiliation/battle dimension matrix.
Figure 2. Affiliations and battle dimensions. Page 2-4
(from page 26 [2-4] of the APP6-B standard PDF, Figure 2. Relevant material on page 26 [2-4] and page 27 [2-5])
The dotted line frames indicate uncertain affiliation.
"...
object being represented. The affiliation categories are friend,
assumed friend, hostile, suspect, neutral, unknown and pending. A
circle or rectangle frame is to denote friend or assumed friend
affiliation, a diamond frame to denote hostile or suspect affiliation,
a square frame to denote neutral affiliation, and a quatrefoil frame
to denote unknown and pending affiliation. A solid line is used to
denote the certainty of identification of affiliation and shall identify
the symbol as friend, hostile, neutral and unknown. A black and
white dotted line (one dot black and one dot white in an alternating
pattern) denotes the uncertainty of identification of affiliation and
shall identify the symbol as assumed friend, suspect, or pending.
Figure 3 shows the black and white dotted lines on various
backgrounds. Each of these affiliation categories is defined in the
Lexicon. The codes for affiliation in the symbol identification code
are included in Annex B.
..."
Present and Planned status are indicated with solid lines, and dashed lines on frames, respectively:
"...
Status. Status refers to whether a operational object exists at the
location identified (status is “present or confirmed”) or will in the
future reside at that location (status is "planned or anticipated").
The symbol frame will be a solid line when indicating present status
and a dashed line when indicating anticipated or planned status (see
Figure 4). Planned status cannot be shown when the symbol is
unframed or is displayed as a dot (see Paragraph 0213.a.). The
codes for status in the symbol ID code are provided in Annex B.
..."
(Page 28 [2-6])
I tested using the Export App and found these 4 conditions were not honored in app6b ( this issue also mentions APP6D - was this tested there also? )
Example SIDC Status/Frame type
SFGAUCI-------- PLANNING/ANTICIPATED (DASHED FRAME OUTLINE)
SPGPUCI-------- PENDING (DOTTED FRAME OUTLINE)
SAGPUCI-------- ASSUMED FRIEND (DOTTED FRAME OUTLINE)
SSGPUCI-------- SUSPECT (DOTTED FRAME OUTLINE)
The script I used to test and output are below/attached.
ExportApp6b-SmallGoodFaithTest.txt
Note: I also updated the Export App deployment to include these "Good faith" test scripts that test frame/modifier combos
Note2: I updated the original issue to include this info to state what is not working and remove APP6D
@csmoore - what do you think is a good way forward for the APP6-B dashed and dotted frames?
Do we need to re-create all of the symbols, the way we have separate symbols for F,H,N,U? Is it possible to inform the dictionary renderer to drop a generic dotted or dashed overlay on the existing symbols, given a known affiliation?
@csmoore - Q: how are the APP6B symbols stored in the stylx file - are they a blob data type? Any SQLITE utilites outside of ArcGIS/Runtime for extracting BLOBs from database? Can we do that and see what file type they might be? Wondering if they are EMFs or SVGs... Perhaps they can be exported as SVG?
If so, we may be able to do some of the frame modifiers (dotted, dashed) by identifying those shape strings in the SVGs and write some code to copy them and tweak the line properties, then reimport.
https://stackoverflow.com/questions/15448373/how-to-dump-a-file-stored-in-a-sqlite-database-as-a-blob
http://www.numericalexpert.com/blog/sqlite_blob_time/
This needs to be logged in the Runtime repo.
I stated above that I need to log an issue in Runtime, but I do not understand what I need to log in Runtime. Can someone provide clarity on what I need to log?
@csmoore will provide guidance on this issue.
The general issue is with dashed lines for frames (on point symbols), lines, and polygon symbols.
Currently the icons for each app6b symbol in the style are a single symbol that includes the frame and other icon components within the frame:
Because of this, it is currently impractical to change the symbol's frame.
We addressed this issue with the 2525B/C/D styles by breaking apart the icons into frame + other icon components.
For app6b we could either:
- Re-author the style similar to 2525D with frame and other icon components broken out into separate icons and change the runtime rule engine to work with this style -or-
- Change the runtime rule engine-drawing pipeline to allow for the insertion of a style override - ex. dash line
a. This would also address the same issue with drawing control measures (non-framed symbols like action points and control measure lines and areas) with dashes lines for planning status
@lfunkhouser is this a call we are supposed to make or is this something that should be made by core?
It is to my understanding that even if we could do #1, we couldn't support planned status for the point, line and area control measures using the provided source data. An issue to support this should be logged in core.