-
Notifications
You must be signed in to change notification settings - Fork 10
ArcGIS Runtime SDK for Java v100.13/100.14 - crashes using Ordered Anchor Points #400
Comments
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 If so, do you know if it occurs on |
Hi @csmoore , sorry for the confusion:
Both versions have the crashes. |
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:
(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. |
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:
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+). |
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. |
@mmarionRH In case you want to provide this info to the support technician - I reported this issue internally as 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
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) |
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. 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:
Thank you for your good support, have a good day |
@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. |
@kerryrobinson thank you for this clarification, have a good day |
@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 |
Hi @pMaske, The work-around only works when using the dictionary renderer. Without it (aka.: by doing a We already have two workarounds that were using in our code. I described them in a comment above:
Thanks |
@mmarionRH , can you please describe this other workflow you are referring to?
|
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. |
@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? |
Hi @kerryrobinson,
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. |
@mmarionRH thanks for trying different workflows and testing different things. However I do want to highlight and clarify that 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! |
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):
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. |
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).
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
The text was updated successfully, but these errors were encountered: