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:
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).
Solved! Go to Solution.
Ok, so here is what I can tell.
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.
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).
Ok, so here is what I can tell.
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
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.
@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 :).