Closed caporossi closed 6 years ago
After some mails with the support I have updated the first post
I met with @csmoore on how to begin approaching this. Have installed Pro 2.0 and downloaded the latest app6B stylx from https://github.com/Esri/military-features-data/pull/294
Copied this into the Runtime symbol generator app and ran the ExportApp6b-SmallGoodFaithTest.bat test. Currently checking the results generated against intended results.
Ran the runtime symbol generator on this set:
S-U-NA---------.png S-U-NBR--------.png S-U-NBW--------.png S-U-NM---------.png SFF------------.png SFF-AF---------.png SFF-AFA--------.png SFF-AFK--------.png SFF-AFU--------.png SFF-AFUH-------.png SFF-AFUL-------.png SFF-AFUM-------.png SFF-AH---------.png SFF-AHA--------.png SFF-AHH--------.png SFF-AHU--------.png SFF-AHUH-------.png SFF-AHUL-------.png SFF-AHUM-------.png SFF-AV---------.png SFF-G----------.png SFF-GB---------.png SFF-GCA--------.png SFF-GS---------.png SFF-GSP--------.png SFF-GSPA-------.png SFF-GSR--------.png SFF-SN---------.png SFF-SNB--------.png SFF-SNN--------.png SFF-SNS--------.png SFF-SNU--------.png SFS------------.png SFS-C----------.png SFS-CA---------.png SFS-CALA-------.png SFS-CALC-------.png SFS-CALS-------.png SFS-CH---------.png SFS-CL---------.png SFS-CLBB-------.png SFS-CLCC-------.png SFS-CLCV-------.png SFS-CLDD-------.png SFS-CLFF-------.png SFS-CM---------.png SFS-CMMA-------.png SFS-CMMD-------.png SFS-CMMH-------.png SFS-CMML-------.png SFS-CMMS-------.png SFS-CP---------.png SFS-CPSB-------.png SFS-CPSU-------.png SFS-ED---------.png SFS-EP---------.png SFS-EV---------.png SFS-GC---------.png SFS-GE---------.png SFS-GF---------.png SFS-GG---------.png SFS-GU---------.png SFS-N----------.png SFS-NFT--------.png SFS-NH---------.png SFS-NI---------.png SFS-NM---------.png SFS-NOT--------.png SFS-NR---------.png SFS-NRA--------.png SFS-NS---------.png SFS-NTS--------.png SFS-O----------.png SFS-XF---------.png SFS-XH---------.png SFS-XL---------.png SFS-XM---------.png SFS-XMC--------.png SFS-XMD--------.png SFS-XMDF-------.png SFS-XME--------.png SFS-XMF--------.png SFS-XMHZ-------.png SFS-XMO--------.png SFS-XMP--------.png SFS-XMT--------.png SFS-XMTR-------.png SFS-XR---------.png SFS-ZI---------.png SFS-ZM---------.png SFS-ZN---------.png SFU------------.png SFU-N----------.png SFU-NBS--------.png SFU-ND---------.png SFU-S----------.png SFU-SC---------.png SFU-SN---------.png SFU-SO---------.png SFU-W----------.png SFU-WD---------.png SFU-WDM--------.png SFU-WM---------.png SFU-WMD--------.png SFU-WMF--------.png SFU-WMFD-------.png SFU-WMG--------.png SFU-WMGD-------.png SFU-WMM--------.png SFU-WMMD-------.png SFU-WMO--------.png SFU-WMOD-------.png SFU-WT---------.png SFU-WV---------.png 114 file(s) copied.
C:\RuntimeSymbolExport\RuntimeSymbolExport\RuntimeSymbolExport\bin\Debug>del *.p ng
C:\RuntimeSymbolExport\RuntimeSymbolExport\RuntimeSymbolExport\bin\Debug>pause Press any key to continue . . .
In the 1.x.4 set, SFS-CMMS------- seems to be an error with the standard - the same code is used twice for Mine Sweeper and Mine Sweeper Support: (page 247 / D-4-3) We have a code for SFS-CMMA------- that draws with the unknown quatrefoil (SFS-CMMA-------.png) It does not appear in the AP6B standard PDF.
CPSU- seems to be drawing correctly now: (page 248 D-4-4)
SFS-NR--------- is still drawing with the AA symbol This is another case of duplicate code in the standard. and
In the 1.x.5, 1.x.6 set I am still seeing the issue with a wrong symbol for OTHER SUBMERSIBLE 1.X.5.1.3 SFU*SO--------- (page 259 / D-5-1)
@csmoore
@lfunkhouser @topowright @ACueva @dfoll
Can you check with Core if this step is still necessary before editing / creating the stylx to be compatible with Runtime :
@BobBooth wanted to double check since these styles now show up as "Mobile Styles" and wanted to verify that we could now just edit them in Pro and ensure compatibility:
Also, @lfunkhouser - do you have copies of the original SVG files used to make these symbols? Would be handy to have, so the bits share the same reference system/scale/etc...
I found the archive of 2525C SVGs, the othersubmersible(rescue,_research,_underwater_tug) set seems to be working. The symbol comes in as 10 pt, looked tiny compared to the unmodified ones, so I boosted it to 25pt (like the others in this group) and it seems to scale correctly.
Updated STYLX with imported symbol from 2525C source SVGs is working in the runtime app:
@csmoore @topowright
@lfunkhouser
This seems to be the correct way forward.
Adapted batch script to test each affiliation:
The Repair Ship symbol case is strange. I can search the style in Pro and it shows up with the AR symbol. However, when I run the runtime app test script I'm getting the AA symbol. Is this a case of mis-tagging in the STYLX? @csmoore
ENY Patrol Antisurface Warfare preview image is drawing in Pro at 20 pixels high while similar ENY symbols are 28 pixels high. Both are supposed to be displayed at 25 point font, so perhaps the SVG for ENY Patrol Antisurface Warfare is smaller than those used for the other symbols The output PNG file from the runtime app is the same size as the others. Re-importing the SVG file from the 2525C SVG cache seems to have solved the problem..
I will pick this up on Monday with MCM Support MCM SUPPORT 1.X.4.1.3.4 SFS*CMMS-------
@BobBooth RE: Repair Ship - there must be another symbol with the same "key" and it is finding that one first - finding and changing the key for the bad symbol is probably the solution - just ping me if you can't locate (since I'm not sure if you can search by "key" in Pro)
@csmoore - actually, the standard itself looks broken. Perhaps there is an errata document for it? SFS*NR--------- maps to two different symbols in the PDF. The original poster mentioned: "... This error is present in NATO APP6B document (same sic has been used twice) addressed by BUG-000086889 ..."
SSCMMS-- also maps to two items in the standard document. This is an error in the standard. Unless there is an errata document correcting this for the standard, I'm not how we are supposed to decide which one it should display as. @csmoore
I'm marking this as impeded again. The things that could be fixed have been. Two items remain: MCM Support (SSCMMS- maps to Minesweeper and MCM Support) Repair ship (SSNR--) maps to Underway replenishment and repair ship) both are due to errors (duplicate use of the same codes) in the standard itself.
It would be nice to have @csmoore's question answered.
@BobBooth - an Errata for these standards would definitely be helpful since they do have errors, but I don't think one exists.
Just need some guidance whether to (1) Pick one over the other, change the other's "Key", add an "Error in the Standard" tag -or- (2) Draw neither -or- (3) something else
@lfunkhouser Please let us know what to do with these two errors in the standard.
@ACueva or @dfoll Please follow up with this issue.
We implement the standard, so if it is an issue with the standard, it should be reported to the JSP/SSMC through @joebayles. Before moving forward with @csmoore options for a solution, please fully understand after working with Joe if anything has been reported with these symbols and what the JSP's recommendation is for the duplicate entries. In addition, document which symbols are not supported and check to see if the symbols have been fixed in the next version of the standard. Also, dig into the question from @csmoore pertaining to https://github.com/Esri/military-features-data/tree/dev/military-symbology-styles/utils-and-source-data/style-creation-utilities#important-warning-on-runtime-compatibility-before-you-begin.
@BobBooth The 2525C svgs were used as a starting point. We did not have APP-6 svgs. @BobBooth Can you supply the tags that you reference in your "mis-tagging" statement/question?
Assigning to @ACueva and @dfoll to dig into this issue
@lfunkhouser - the APP6-B standard has the same SIC for Repair Ship and Underway Replenishment. What we draw, when given the input code, is the first one that is comes to, which is the AA (UNDERWAY REPLENISHMENT) symbol, rather than the AR symbol. https://camo.githubusercontent.com/e2a2c6a37f14a14ca43aa19a52d293b9d8962b74/68747470733a2f2f696d616765732e7a656e68756275736572636f6e74656e742e636f6d2f3561306630353162386137353838346239303837646265652f35646331373063332d393061352d343735662d616236352d346265356561636130353430 In Pro, the item properties are:
Repair Ship: Tags: APP-6(B);Annex D;Appendix 4;Sea Surface Track;Non Combatant;Repair Ship;Equipment;Friendly;SFSPNR----***** Key: SFSPNR----
Underway Replenishment: Tags: APP-6(B);Annex D;Appendix 4;Sea Surface Track;Non Combatant;Underway Replenishment;Equipment;Friendly;SFSPNR----***** Key: SFSPNR----
@lfunkhouser E-mail sent to Runtime team for clarification on @csmoore 's questions.
Path forward: Research behavior in 2525B to see if there is a typo or other minor issue. @BobBooth will research this behavior in 2525B Result: Table with differences. Provide this table for @joebayles and @lfunkhouser.
Reached out to Ralf G. on the Runtime team: Q: 1. Do we still need to perform the following steps before editing/creating a stylx for it to be compatible with runtime? https://github.com/Esri/military-features-data/tree/dev/military-symbology-styles/utils-and-source-data/style-creation-utilities#important-warning-on-runtime-compatibility-before-you-begin
A: "... they don’t look necessary anymore now that Pro introduced the mobile style files. Mobile style files contain all the flags necessary to convert Pro CIM and make it Runtime compatible. Like creating vector marker symbols, densifying curves, forcing RGB colors, etc."
Q: 2. Our style files show in ArcGIS Pro as a “Mobile Style”, any idea if we were to edit these style files in ArcGIS Pro, would they still be compatible with Runtime? A: 2. They should be compatible with the Runtime, Pro looks for those flags I mentioned above and converts the symbols to the compatible format when you save.
This was tested in Runtime 100.1
Next step will be for @ACueva to log an issue in the :
@lfunkhouser - in the APP-6D PDF, the AR symbol seems to mean Repair Ship
@ACueva @dfoll There are a couple of issues with Landing Support: SFG-UUX- According to the APP6-B PDF, the SIC should be SFG-UUL-
However, this SIC is also duplicated in the standard and represents Law Enforcement Units: LAW ENFORCEMENT UNIT 1.X.3.1.2.3 SGUUL---*****
Our Landing Support symbol Key is: SFGPUUP--- Need more information of whether ours should be switched to SFG-UUX- @joebayles - any thoughts?
@dfoll @ACueva @topowright Please read all comments in this issue, understand the issue, and identify the remaining work that needs to be completed.
We should stick with our current SIC SFGPUUP--- for Landing Support and SFGPUUL--- for Law Enforcement, these match the usage in the 2525C standard, the APP6B stadard PDF seems to be in error). See notes in https://github.com/Esri/military-features-data/issues/85
Changed our symbol for Underway Replenishment to the AR symbol, updated tags in stylx.
Changed our App6B symbols for MCM Support to use SFSPCMMA-- SICs instead of SFSPCMMS-- This is the way it is in 2525C. MS is minesweeper.
Script to test Issue 88: Issue88_test.zip Issue 88 test script output:
All work was completed on this issue in a previous sprint by @BobBooth. The remaining effort is verifying that they are fixed. @ACueva Has this been verified as fixed?
Continue our analysis of the symbology APP6 (B)
The tests were carried out with:
ArcGIS Runtime SDK for Java 10.2.4 dictionary app6b.dat version 1390944071 The families of symbols as grouped in the same Hierarchy find in APP-06 (B) Joint Symbology.pdf
geomessage all symbol 1.x.4
geomessage all symbol 1.x.5 1.x.6