missing entries from V100.0 to V100.1

[NorbertThoden]

Hi! Ich use the military symbology and have problems with a couple of symbols. Lets focus on Protection Areas : Assault Crossing (key=25271300):

I am using the method 'searchSymbols(SymbolStyleSearchParameters) to search for key=25271300: Using ArcGisRuntimeQt (C++) V100.0 - Linux i got 4 of symbolClass 5, 1 of symbolClass 3 Using ArcGisRuntimeQt (C++) V100.0 - Linux i got just 4 of symbolClass 5. A result of symbolClass 3 is missing.

If i look into the stylx file they differ in the same way: V100.0:

V100.1:

Why is the result with symbolClass 3 missing?

Thx in advance! Norbert

[Dbarnes1]

@NorbertThoden in order to more accurately depict the Assault crossing, we changed the symbol class from Area to Line, or class 3 to 4. Previously, you would sketch a polygon with the assault crossing symbol in the center of that polygon, but now the symbol draws as a line from start point to end point. This was done to fix a bug submitted against the stylx at version 100.0. Let me know if you have any questions.

[NorbertThoden]

Hi Daniel! It´s not unlikely that i created the bug...

But how can i get the image:

From my point of view this entry is completely missing, as shown in the screenshots. Or does that entry has a different key? Thx

[Dbarnes1]

@NorbertThoden Sorry for misunderstanding. We did get rid of the Protection Areas : Assault Crossing without any affiliation, but we kept the 4 versions of the symbol that have affiliation. In the stylx, I would search for any Key that is like "271300" and then choose one of the symbols depending on affiliation. Friendly, which is black, is 271300_3 in our stylx.

[NorbertThoden]

And this is done for "Protection Areas : Assault Crossing" or for any other symbols?

[Dbarnes1]

This is how we structured all of our symbols, dividing their Keys with the 4 affiliations, although there are cases in which we may have an entry that doesn't have an affiliation (METOC symbols). Our intent is to get rid of confusion by eliminating duplicate entries in the stylx.

[NorbertThoden]

Eleminating duplicates is good idea .-) But it should be possible to get the image used in the official document (MIL2525D):

The suggested symbol (black, key=25271300_3) is (a little bit) different.

ESRIs make it hard to use their SDK sometime.... I will how is can come across this problem...

Thanks for the information!

[NorbertThoden]

Hi Daniel! I tried to analyze the 3 similar symbols:

Overview

(Taken from MIL2525D)

• 25271100 - 4 PTs - Protection Areas : Bridge or Gap
• 25271300 - 4 PTs - Protection Areas : Assault Crossing
• 25271400 - 3 PTs - Protection Areas : Bridge

Number of entries in stylx:

V100.0 is using stylx in version 1.0, build 4851 (as shown above) V100.1 is using stylx in version 1.0, build 7198 (as shown above)

• 25271100 - V100.0: 5 entries ; V100.1: 5 entries
• 25271300 - V100.0: 5 entries ; V100.1: 4 entries
• 25271400 - V100.0: 5 entries ; V100.1: 5 entries

For me it looks inconsistent.... In other words: Entry with key "25271300" SymbolClass 3 is missing.

This lead to problems in creating a overview and let the user select a symbol (and start the creating process...)

Preview/swatch images

The Api methos searchSymbol() returns a symbol and afterwards createSwatch() can be used to render an image. The following screenshots are displaying an overview: (Pay attention to the order of the symbols and ignore column "fetchSymbol")

V100.0: stylx in version 1.0, build 4851

V100.1: stylx in version 1.0, build 7198

Problem: The Column 4 "symbolPropertyImage(EsriSearch..) has a surprising image for 25271300_4...

For me it looks inconsistent again....

In V100.0 we were having 3 (correct) preview/swatch images and we were able to create at least one on the map (but with problems). Therefore we created a support case and a bug (BUG-000103127) Now in V100.1 we have one missing/wrong preview/swatch image, and no of this 3 symbols can´t be displayed on the map....

What do you think?

Thx

[NorbertThoden]

Hi Daniel!

With our current knowlegde we put some hours and analyze the construction of these 3 symbols:

We modified the construction of theses 3 symbols to use 4 coordinates. Using the V100.0 this looks like: As you can see, 25271300 looks awful

Using V100.1 it´s really fine: (Please ignore different colors)

So my conclusion is: Construction of there 3 symbols is ok in V100 - fine, thank you for fixing the original bug.

The swatchSymbol (aka previewImage) if 25271300 is missing since you tried to

Our intent is to get rid of confusion by eliminating duplicate entries in the stylx.

So my question is: Can you re-think the modification you did and take 25271100 and 25271400 into account? From my point of view this should lead to re-add the removed entry and make it similar/consistent to the 2 other symbols. Can you update the stylx and and release the fixed version? Or do we have to create an official bug request? (And it will take much effort at ESRIs and our side).

What do you think?

Thank you Norbert

[Dbarnes1]

Hi @NorbertThoden,

Thanks for doing such an in-depth investigation. I am glad that we agree that the original bug was fixed in V 100.1.

For 25271300, it would be easy to add the 5th symbol for consistency, but I believe a better fix would be to use 25271300_3 as the swatchSymbol. I would argue that because we have 4 affiliations for these three symbols, we should actually remove the 5th entry in 25271100 and 25271400. I can add the symbol back if necessary though.

[NorbertThoden]

Hi Daniel!

Thanks for doing such an in-depth investigation. I am glad that we agree that the original bug was fixed in V 100.1.

Thanks you for honoring my work and the result. I try to establish a good workflow between ESRI and me (or my company) since about 2 years. I prefer to work together.

But back to topic: I would prefer this, especially if it´s easy.

Why:

1. the swatchSymbol of 25271300_3 does not really match the standard document MIL2525D For this purpose the 5th symbol (with SymbolClass 3) is in the stylx. MIL2525D: 25271300_3:

2. There are about 2000 final entries / symbol in the stylx (the match an entry in the standard document MIL2525D. I estimate that there are ~1000 point symbol, ~200 line and ~250 area symbols. For all of the relevant 450 line/are symbol there are 5 symbols: one with SymbolClass 3 and 4 with SymboClass 4 or 5.

3. From my point of view (and maybe confirmed by Chris Moore - but i can´t really remember) the sense of the 5th (SymbolClass 3) is to have a swatchImage usable as previewImage)

Maybe there are more arguments, but i hope that these are already convincing to you/ESRI. Ok?

[Dbarnes1]

@NorbertThoden you are absolutely correct. I will add that symbol with symbolclass 3 back into the stylx and I will let you know once it is updated. It won't get pulled into runtime until the next release, but I will post a link here on GitHub where you can access the latest.

[NorbertThoden]

Hi Daniel! Just a short answer is necessary: Thank you very much I am looking forward to hearing from you. Have a nice weekend Norbert

[Dbarnes1]

@NorbertThoden symbol has been added back in the stylx and is fixed; will be released in the next version of Runtime. In the mean time, you can download the stylx from our github repository here: https://github.com/Esri/military-features-data/blob/dev/data/mil2525d/core_data/stylxfiles/mil2525d.stylx. I'm going to go ahead and close this issue.

[NorbertThoden]

Hi! I just tried out V100.2 / Update 2. Unfortunately the problem isn´t solved here. So i requested a case: "#02038572 missing entries from V100.0 to V100.1, still missing in V100.2"

[Dbarnes1]

Hi @NorbertThoden. Have you tried using the link I posted above with Update 2?

[NorbertThoden]

Hi Daniel! No, not with Update 2. I checked that modified stylx at in July 2017. I was very happy with our discussion that looks like i was able to convince you and the result was a fixed stylx. The check results were fine. Now, with V100.2/Update 2 i expected that the associated stylx would contain this "fix". Do you know why not? Thanks

[lfunkhouser]

FYI @topowright @dfoll @ACueva - Can you dig into when this update will be available with Runtime

[Dbarnes1]

@NorbertThoden just following up here, under Esri's Military Symbology Styles solution is a link to the updated .stylx file which should have the fix you are requesting. This file can be used with Runtime 100 Update 2.

Here is the link: http://solutions.arcgis.com/defense/help/military-symbology-styles/

Just click on the "Download MIL2525D" button to get the .stylx.

Rather than on GitHub, the link above is the authoritative source for the latest .stylx files for Runtime

[NorbertThoden]

Hi Daniel! Greeting from Germany! I got a mail regarding Case 02038572 / BUG-000110500 - mil2525d.stylx missing expected Key:25271300 in 100.2 release:

Before release, the Runtime SDK for Qt gets the most recent version of the stylx files from http://solutions.arcgis.com/defense/help/military-symbology-styles/. Unfortunately at the time of release this was not updated with the changes made to the file to fix the issue reported. This site has now been updated with the latest version of the stylx file, which fixes the issue. The mil2525d.stylx file released with Runtime 100.2 should be replaced with this most recent version. <<<

Neverless i would like to thank you for your comment updating this issue!

I downloaded that file and compared the size: 23734272 bytes So i assume the file are identical - perfect

Thx

[NorbertThoden]

Hi! I tried the new arcace-based symbology using the QT-SDK. Unfortunately problems similar to this thread arises...Maybe the arcade-based symbology is not finished!? Does someone knows the status or a forum where i can get answers regarding the arcace-based symbology? Thanks in advance. Norbert

[joebayles]

@jeconley can you respond to @NorbertThoden ?

Thanks!

[jeconley]

@NorbertThoden is the issue that the symbol is drawing incorrectly or that preview of the image is incorrect?

[NorbertThoden]

Hi! Maybe both!? Regarding swatch: I´m in trouble getting the correct symbol and afterwards the swatch to generate a type specific swatch: Maybe fetching and searching an item will return different symbols (and therefore swatch images):

Additional: I tried one of the GitHub example: Esri-GitHub-ExamplesV100.6/arcgis-runtime-samples-qt/ArcGISRuntimeSDKQt_CppSamples/Search/SearchDictionarySymbolStyle For one of my favorite 25 270100 (obstacle belt) i got three result:

1. 25 270100
2. 25 270100_
3. 25 270100_label But the swatch symbol isn´t usable comapred to the one of the standard:

Regarding drawing: Kerry Robinson wrote: "Sorry I wasn't more clear in my previous email. We use the term "control points" internally to refer to control measures that use anchor points. While we have made many improvements in the new arcade-based dictionary styles, we have not yet implemented support for the use of anchor points. In the older dictionary styles, we only supported the use of anchor points if multi-point geometries were used. This solution does not work well when these dictionary styles are used with other ArcGIS products which support data formats where the ordering of points cannot be guaranteed. Therefore we are working on a solution that will work across all ArcGIS products. "

So, i hope that the "control points" will be supported with the next release. But how can i get updates of the arcade-bases stylx?