identifyGraphicsOverlays for some sidcs not working

1686
9
03-28-2017 02:13 AM
NorbertThoden
Occasional Contributor III

I create a GraphicsOverlay and put a advanced symbol on it. This is done using a DictionaryRenderer (MIl2525D)

The task "identifyGraphicsOverlays" is done on a sidc "10032500001406030000"  // SymbolSet/Entity = 25 140603

(line with arrow)

The slot "identifyGraphicsOverlaysCompleted" is called but with an empty result list 😞

Conclusion:

Many (maybe all) multipoint sidcs can´t be identified/picked.

0 Kudos
9 Replies
LukeSmallwood
Esri Contributor

Hi Norbert - thanks for posting your question. Do you have any example code you could share?

One other thing which might be worth double-checking is that your are connecting to the correct signal for the task you have started. E.g MapQuickView has 2 signals:

identifyGraphicsOverlayCompleted
identifyGraphicsOverlaysCompleted

corresponding to the 2 tasks:

identifyGraphicsOverlay
identifyGraphicsOverlays

Note the "s" at the end of "GraphicsOverlay" for the 2nd signal (this has caught me out before).

It might also be worth connecting to the errorOccurred signal if you haven't already done so.

Thanks,

Luke

0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

Thanks for the quick answer!

We are using the pure C++, no Quick/QML.

And yes, i know the two similar named signals/slots.

If i use another sidc (like a point symbol) than it works. (Since ~1,5 years)

example - will try to build...

0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

Description:

I create two PictureMarker as dummy object:

  • - one in green and a size of 20;
  • - one in red and a size of 10;

I add an attribute to distinguish them.

I create an advanced symbol: 10032500001406030000 // 25 140603

The problem is related to the identifyGraphicsOverlays method which is overloaded:

  1. // First overload:
    // Identify the topmost graphics in all the graphics overlays at the specified screen coordinates.
    TaskWatcher identifyGraphicsOverlays(double screenX, double screenY, double tolerance, bool returnPopupsOnly);
  2. // Second overload:
    Identify which graphics in all the graphics overlays appear at the specified screen coordinates.
    TaskWatcher identifyGraphicsOverlays(double screenX, double screenY, double tolerance, bool returnPopupsOnly, int maximumResultsPerOverlay);

Behaviour:

  • For the first overload: (topmost)
    The the two PictureMarker can be picked/identified as well as advanced symbol.
    (They can be recognized the the attribute
  • For the second overload: (more than one result per GraphicsOverlay)
    The  two PictureMarker can be picked/identified but not the advanced symbol

This is true for RenderingMode::Dynamic.

Using RenderingMode::Static, the advanced symbol could never be identified/picked....

My Conclusion:

The second overload does not return the advanced symbol

Do i miss something?

LukeSmallwood
Esri Contributor

Thanks Norbert - that does sound like a possible bug. I'll try and reproduce with your example code and log a bug.

0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

It would be very kind if you keep me up-to-date.

This bug is very important for us!

Thx

0 Kudos
LukeSmallwood
Esri Contributor

Hi Norbert,

I have built your code and can reproduce the behaviour you describe:

using overload 1 and clicking on all 3 symbols I get the topomost graphic e.g. the advanced symbol:

identifyResults.size= 1

[[[ iResult= Esri::ArcGISRuntime::IdentifyGraphicsOverlayResult(0x266776516b0) (#Graphics within result= 1 ) ]]]

retrieved AttrVal= ""

using overload 2 and clicking on all 3 symbols I get just the simple marker symbols:

identifyResults.size= 1

[[[ iResult= Esri::ArcGISRuntime::IdentifyGraphicsOverlayResult(0x266774181f0) (#Graphics within result= 2 ) ]]]

SimpleMarkerSymbol

retrieved AttrVal= "drawPictureMarker:r=10"

SimpleMarkerSymbol

retrieved AttrVal= "drawPictureMarker:r=20"

I will see if I can come up with a simpler repro using our latest version and log a bug.

Thanks for reporting this!

Luke

NorbertThoden
Occasional Contributor III

Hi Luke!

Thanks for your time 🙂

In a similar case (during at the early adapter) forum Luke L. said to me:
"Lucas Danzinger, 23.11.2016: "Norbert- I can reproduce this and it definitely appears to be a bug. Since you have already logged this through the beta community, I'll go ahead and export this as a bug into our system, and there is no need for you to contact support about this specific one."

In at least two similar cases (NOT during at the early adapter) Lule L. pleased me to explicit log a bug at the official support.

What do you recommend for this case?
It´s a critical bug for us. It is more than desirable to monitor this.
Maybe it´s helpful to log this as a customer bug (more severity?), to be able to monitor, escalate etc.
What do you think?

Maybe wait until you can tried to reproduce the bug with your latest version?

Thx

0 Kudos
LukeSmallwood
Esri Contributor

Hi Norbert - I just finished reproducing the problem using a simpler block of code (based on one of our samples) and with our latest version.

I've already logged a bug with this repro case: I will confirm with Lucas whether you should also log a support bug and get back to you.

Thanks,

Luke

0 Kudos
LukeSmallwood
Esri Contributor

Hi Norbert,

It is probably a good idea to log a bug with support for this issue as well - that way they will be aware of the problem if anyone else reports and so on.

Thanks,

Luke

0 Kudos