ArcGIS Runtime SDK for Java v100.13/100.14 - crashes using Ordered Anchor Points

[mmarionRH]

Hi,

When using the latest stylx file (https://www.arcgis.com/home/item.html?id=4e31ddc1f609432d98bd400f87f6b7bf) with ArcGIS Runtime SDK for Java v.100.13 and the "Ordered Anchor Points" feature, there are two situations where a crash occurs (not exceptions, instant crashes).

• Most entities (the ones that uses Ordered Anchor Points) will crash if you only place one point on the map.
  • 
• The “Protection Lines : Trip Wire” entity will crash when the first two points are placed at the exact same location.
  • 

I did a Gradle sample (which has been updated to ArcGIS 100.14) to showcase these issues: OrderedAnchorPointsCrashesSample.zip

In the sample, use add/set points buttons with an asterisk to reproduce the crashes.

To run the sample, update the api key and the path to the MIL-STD-2525C stylx file.

Thanks

[csmoore]

I can try your sample - since we were dealing with 2 different versions I just wanted to confirm that this crash occurs+should be tested on 100.13 (vs. 100.14 that we were discussing in other issue).

If so, do you know if it occurs on 100.14?

[mmarionRH]

Hi @csmoore , sorry for the confusion:

• We first noticed these issues on 100.13.
• Then, when I was suggested to create an issue on this github, I did this Gradle sample and tested 100.14 while I was there.

Both versions have the crashes.

[csmoore]

I did try your sample (thanks for providing another great repro sample) and was able to repro the issue on 100.14 - so I can report this internally:

1. Control Measure Dictionary Renderer Symbols that use ordered achor points crash when geometry only has one point (tested in mil2525c with ordered achor points enabled)
2. Trip wire symbol crashes when using ordered achor points and 1st and 2nd point are same location (tested in mil2525c with ordered achor points enabled)

(just restating to make sure I got this right)

It definitely shouldn't crash and hopefully you can work around for now knowing the trigger. If this is not more of a Chaos Monkey test case but a normal/expected case for something that you would be interested in a patch for - you should also initiate a ticket with support.

Final note: I also tried in Pro, but because the Pro preview always supplies the 2nd point (and requires at least 2 points to complete a line sketch), I wasn't able to see if I could trigger there.

Sorry these edge cases slipped through our testing.

[mmarionRH]

Support case is already done, a bug report was made out of it. Still, the person who helped me suggested that I create an issue here too, so that's what I did :)

And I can confirm those are normal/expected cases. The reason is: in our app, we preview the shape while drawing it (and because of that it is possible to draw it with only one point during a brief moment).

We did some patches to:

• duplicate the first point of control measures that only have one point;
• move 2nd point of a trip wire by a very small distance if it is identical to first point.

Those are patches that should not be needed, but at least we have those workaround for the moment.

About your final note, I don't know ArcGIS Pro much, but if you can set points by manually entering values into text boxes instead of clicking on the GIS, you can probably test the Trip Wire crashes by making sure the first two points are identical (I guess that's how they could confirm in the bug report that it was happening in ArcGIS Pro 2.9+).

[jeconley]

I have not been able to reproduce the crash in Pro. Because of the validation of the geometry you need to create the feature first and then edit the location of the vertices. I am able to validate the symbol after doing that and I don't see a crash.

[csmoore]

@mmarionRH In case you want to provide this info to the support technician - I reported this issue internally as orion#884

Something else you may want to work out with them is: when I looked up that ticket # BUG-000149000 - from the description it sounded like both your incidents

• Incident: 03014505 - previous one described in https://github.com/Esri/military-symbology/issues/399 -> java#6838 --> orion#869
• Incident: 03011514 - this one ( #400 ) - orion#884

May have gotten mapped to the same bug ID: BUG-000149000 - that may be normal - but worth mentioning. If there are more issues we probably need to coordinate a better process with support so I don't interfere with their normal process and create duplicate issues (which I discovered happened with the first one you reported - but I am happy we were able to speed that fix up even if it caused some internal confusion with the duplicates - so many thanks again)

[mmarionRH]

Hi @csmoore, from what I understand, it is well intended that both those cases point toward the same bug. What ESRI Canada told me: "Esri Inc has logged a bug for this issue and we're classifying this problem as in our other case (03014505) under the same bug.".

I'll let them know about orion#884. EDIT: I forgot that the support case is closed, and all that remains is the bug, which from what I understand seems already linked to orion#884, so everything should be good.

Also, I must admit that I'm a little bit confused too as why I have to post here when I already have a support case. What they told me in previous mails:

• "I can suggest to check and maybe post an issue on the github page here: https://github.com/Esri/military-symbology/issues"
• "We do infrequently suggest that issues be submitted through to GitHub pages. The reasoning for this is that the product is often created and managed by a very specific and small team within Esri Inc. These tertiary products don't always follow our classic escalation and defect submission process because of the teams size and structure, and these teams prefer to track issues through GitHub. This does not mean that we will not also submit a classic defect in addition to the GitHub issue you submitted, however. They can be used in combination to help resolve issues more quickly."

Thank you for your good support, have a good day

[kerryrobinson]

@mmarionRH Thank you for your thorough reproducers and details, and I understand your concern with sharing this information in two places. What it basically boils down to is that any bugs that are discovered should go through our more formal Technical Support channels - one of the main reasons is so that the bug information is visible to yourself and others to track. However specific to Military Symbology, because of the nature and complexity of the symbol specification itself, the development team does appreciate more direct contact with customers who are reporting problems. We should be able to work together more quickly to triage the problem, to confirm bugs or suggest workarounds.

Hopefully, that helps. Feel free to use this repo at any time to report any feedback to the team or to ask questions relating to military symbology and the dictionary renderer.

[mmarionRH]

@kerryrobinson thank you for this clarification, have a good day

[pMaske]

@mmarionRH , we have been able to reproduce the problem and are working on fixing this. Good news is there is very viable workaround that can help you move forward.

In method updateEntity (line number 260) can you please change geometry type from Polylineto aMultipPoint` and try all your workflows? We want to make sure we capture workaround will work for all of your test cases

[mmarionRH]

Hi @pMaske,

The work-around only works when using the dictionary renderer. Without it (aka.: by doing a graphic.setSymbol(...)), it gives the following result:

We already have two workarounds that were using in our code. I described them in a comment above:

We did some patches to:

• duplicate the first point of control measures that only have one point;
• move 2nd point of a trip wire by a very small distance if it is identical to first point.

Thanks

[pMaske]

@mmarionRH , can you please describe this other workflow you are referring to?

Without it (aka.: by doing a graphic.setSymbol(...)), it gives the following result:

[mmarionRH]

Hi @pMaske,

With the Java API, to set the symbol of a graphic, you can either use the dictionary renderer (which implicitly set the graphic's symbol) or load a symbol directly from the dictionary symbol style and set it to the graphic.

Here's some code from a sample I used in another support case. The first method is an example of how to manually set a symbol to a graphic. The second method is an example of how to use the dictionary renderer.

private void createGraphic(Entities entity) throws InterruptedException, ExecutionException
{
    // Create graphic, set its geometry and add it to graphics
    Graphic graphic = new Graphic();
    graphic.setGeometry(new Multipoint(new PointCollection(SpatialReferences.getWebMercator())));
    _graphicsOverlay.getGraphics().add(graphic);

    // Load symbol from dictionary
    Map<String, Object> attributes = new HashMap<>();
    attributes.put(SIDC_KEY, entity.getKey());
    Symbol symbol = _dictionarySymbolStyle.getSymbolAsync(attributes).get();

    // Set graphic's symbol
    graphic.setSymbol(symbol);
}

private void createGraphicInDictionaryRenderer(Entities entity)
{
    // Dictionary renderer
    DictionaryRenderer renderer = new DictionaryRenderer(_dictionarySymbolStyle);
    _graphicsOverlayDictionaryRenderer.setRenderer(renderer);

    // Create graphic from attributes
    Map<String, Object> attributes = new HashMap<>();
    attributes.put(SIDC_KEY, entity.getKey());
    Graphic graphic = new Graphic(new Multipoint(new PointCollection(SpatialReferences.getWebMercator())), attributes);
    _graphicsOverlayDictionaryRenderer.getGraphics().add(graphic);
}

The provided workaround (to use a Multipoint geometry instead of a Polyline) works fine when using the dictionary renderer (aka.: the 2nd method in the provided code), but not when manually loading a symbol and setting it into a graphic (aka.: the 1st method in the provided code).

Here's a demo that compares the result with and without the dictionary renderer:

I hope it helps! I just want to reiterate that we do not need workarounds, as we already coded some in our app :) I just wanted to point out that using a Multipoint doesn't work well without the renderer.

Thank you, have a good day.

[kerryrobinson]

@mmarionRH Thank you for the clarification, including the code and demo video. Just to make sure I understand correctly... with the workarounds in place, you do not need an urgent fix to BUG-000149000, correct?

[mmarionRH]

Hi @kerryrobinson,

with the workarounds in place, you do not need an urgent fix to BUG-000149000, correct?

This is exact.

Of course, we still could find new situations where those Ordered Anchor Points crashes occur (so many entities and possibilites), but for now we were able to patch how our geometries are created to avoid the reported crashes.

Thanks.

[pMaske]

@mmarionRH thanks for trying different workflows and testing different things. However I do want to highlight and clarify that **Ordered Anchor points** are only effective with Dictionary Renderer (with ordered Anchor Points). Symbols using Dictionary Renderer with ordered anchor points are dynamically generated and based on the attributes of the feature different geometric effects and/or other overrides are applied dynamically as well. All this logic/magic happens via arcade script defined in Dictionary renderer.

So, if you are just fetching the symbol from stylx using an attribute and using that symbol for a graphic, it won't have any effects/overrides or ordered anchor points. At this point it is like any other simple symbol you would apply to a graphic. It has no knowledge of any effects and overrides or custom arcade script that facilitates building the symbol.

That's the reason you are seeing symbols look different without Dictionary Renderer. Please feel free to ask any questions you may have regarding this. I wanted to ensure there is no confusion about usage of ordered anchor points and dictionary renderer and is used correctly in all workflows in your app.

Thanks again and Have a great weekend!

[mmarionRH]

Hi @pMaske,

Not sure if this is pure luck, but I got to say that the Ordered Anchor Points entities mostly work well without the dictionary renderer when using a polyline. According to release notes 100.13, lines are supported (and they are expected for ArcGIS Online and Enterprise according to the note on the page).

In fact, the only differences that I experimented in-between using the renderer or not when testing the 600+ entities we are using are listed in a support case I did (see case #03011491).

Here are some entities we implemented in our app that supports Ordered Anchor Points without the dictionary renderer (names might differ a bit, let me know if you search for a specific entity in the stylx and cannot find it):

• Isolate
• Occupy
• Secure
• Retain
• Attack by Fire
• Ambush
• Main Attack
• CounterAttack
• Supporting Attack
• Axis of Advance Aviation
• Relief in Place
• Delay
• Retire
• Withdraw
• Dummy (Feint)
• Support by Fire
• Block
• Clear
• Contain
• Breach
• Bypass
• Canalize

In any case, we are currently looking at a way to implement the renderer in our app since we see that this is the main, intended path to use. This should help a lot in the near future.

Still, as we already have some workarounds, using the renderer or not is not important for this case. My previous comment was just to point out that Multipoint doesn't work with the renderer, thus we'll keep our current workarounds :) And this case still matters since the crashes can be reproduced using the renderer or not.

Thank you, have a good weekend.