Bug: 4.25 identify operation not working as expected

[BryanMc]

Attempting to use the API Identify operation with identifyParameters to identify on a map service. Goal is to have the results return to the popup with popup highlight graphic on the map. There are some bugs based on setting various identifyParameters not working as expected or sending lots of additional fetch requests (based on 4.25). The starting point was using the API Sample:

1. Works: If set layerIds and returnGeometry false (don't set sublayers): Identify returns, popup shows and no highlight graphic [makes sense]
2. Issue: If set layerIds and returnGeometry true (don't set sublayers): Identify returns (with geometry), popup shows but not highlight graphic [issue as should be able to see highlight graphic].
   • seems like a separate issue where the PopUp doesn't show the highlight graphic properly. Can replicate issue by sending a feature with graphic to the popup and it will not show the highlight graphic.
3. Issue: If set sublayers (with or without layerIds): Identify returns, popup with highlight graphic - Seems good at first but it sends 2 additional fetch requests, a query request and map export request. The identify return graphic will show for split second but is then replaced by the extra query response graphic. Extra query/export requests shouldn't be needed/called and adding lots of chatter.
   • If many features in popup, scrolling to next feature will continually call the additional query and export requests each time as well.
4. Issue: Setting maxAllowableOffset and sublayers: The maxAllowableOffset is honored in the identify response, but then replaced by the extra query response graphic (and query result graphic doesn't honor the maxAllowableOffset). Extra query/export requests shouldn't be needed/called (also does this for each 'Next feature' in popup too).
5. Issue: Setting sublayers with returnGeometry false: Still always does the extra 2 fetch requests (query/map export) and shows the popup with a graphic. The Identify response honors the returnGeometry setting but is ignored for the additional query request.

Hoping I'm just missing something here, any thoughts on workarounds would be appreciated. I did attempt writing an esriRequest to the map service rest identify endpoint. Everything works except the showing of the graphic highlight in the popup (same as #2).

[ReneRubalcava]

Can you provide a codepen or GitHub sample of these issues? Identify is unrelated to Popup and highlight, so unsure how you're hooking them up.

[BryanMc]

Hi @ReneRubalcava , here is a CodePen: https://codepen.io/bmcintosh/pen/jOKzzzr

With the dev console you will see the extra requests. Changing some of the IdentifyParams will lead to more of what is described above. The existing pen, you will see the identify result shape flash quickly (generalized shape), then will change to a detailed shape from query response.

The query/export requests after identifying are puzzling and hoping I'm just missing something (always a possibility on that one).

[ReneRubalcava · Accepted solution]

Ok, so here is what I can tell.

1. Works as expected

2. There is no highlight because the results are not related to the layer. As in, the MapImageLayer has no direct connection to the returned features.

3. Using sublayers works with popup highlight, because the sublayers are part of the MapImageLayer, and that's why it works. The extra export call may have to do with MapImageLayer Popup highlight functionality. We can look at that for next release.

4 and 5: Same as 3, because you are using sublayers from the MapImageLayer, that query highlight functionality is working as expected. Can look into the extra export request for next release.

The couple of extra requests you see are related the MapImageLayer Popup Highlight functionality added at 4.25. We can look and see if that is expected for next release, but for now, I believe it is.

Basically, if you only use layerIds, the results have no relation to a layer at all. When you use the sublayers, they do and you get some extra functionality. You can only use one or the other, I think sublayers takes precedence in that case.

[BryanMc]

Thank you @ReneRubalcava .  The information for #1 and #2 make sense, thank you.

From testing I can see that layerIDs and Sublayers work together for #3-#5 (if I say visible and layerID 4,5 and provide sublayers: it will modify the layer list before sending to cross reference the two lists (so if layer 4 visible is false, will not send [in a good way]).

I added an Interceptor to a query request for the state layer (if you identify a State or two), and you can see that by blocking the Query request it also doesn't do the map export request either - but the results to the popup work correctly from what I can see. Having fewer requests, and reduces server impact. Hoping can be sorted in a future release. A CodePen with Interceptor: https://codepen.io/bmcintosh/pen/mdKxLOe

[JoelBennett]

OP is evidently talking about this sample, and modifying the IdentifyParameters.  The behavior appears to be related to the new MapImageLayer highlight feature of 4.25.

It appears there's an expectation that setting returnGeometry to true will automatically highlight the feature on the map, but the API has never worked this way.  One must manually create a symbol and add the graphic to MapView.graphics or something similar.

However, OP has noticed that when specifying returnGeometry and sublayers, the feature does get highlighted (new to 4.25).  Under the hood, the identify operation retrieves the features as graphic objects (as expected), but when sublayers is specified within the IdentifyParameters, the operation sets an undocumented property called "sourceLayer" on each returned graphic with the related Sublayer object associated with that graphic's layer.  The graphic having this sourceLayer property specified is what triggers the highlight when the graphic is added to the Popup.

This can be demonstrated by adding the following line immediately above original line 148 (return feature):

feature.sourceLayer = identifyLayer.sublayers.getItemAt(result.layerId);

...and the following line above original line 80:

params.returnGeometry = true;

The subsequent highlight operation causes the additional query request.  I would agree with OP in that the query is unnecessary since the geometry already exists on the client, but it is what it is.  Regardless, though, the query is often worse that it looks.  It should only retrieve the specified feature by its objectID value, but it seems more often than not, it doesn't include the objectID in the request, and therefore requests all features in the layer (see attachment)...which is really bad.

I've also seen the additional calls to export mentioned by the OP, but it seems kind of sporadic (not in the attachment for that run), but never actually does anything useful when it does execute.

[BryanMc]

@JoelBennett some great additional insights here! With the Interceptor example you can see we can block the extra requests and still get the desired outcomes but this might not always be the situation (cached map or other various source differences possibly). But agree, it is what it is and we try to work with it. I'm sure a few extra queries to the server won't hurt too much in the meantime (I hope Dave Peters doesn't read this :).