How to avoid full query with identify

[BrianKeller]

Hi, we are using identifyLayersWithMaxResults to identify features where a user has clicked on the map. We only need to know a minimum amount of information about the features identified (like Enums.QueryFeatureFieldsMinimum), which we believe the client should already have in hand from the extent queries. However we see that REST API queries are always firing to the backend to get the full features using object_id. Is there any way to avoid these API calls with identify, or with any other similar method? In our use case, we have to query the layers again using a different identifier than object_id. So just trying to avoid these "duplicate" queries for performance reasons. Thanks!

[LucasDanzinger]

Performing an identify will return a fully loaded feature, which means it will do a query to the service to get all fields. Currently there is no way to configure this to avoid the network traffic.

[BrianKeller]

Thanks for the reply. One thing we are trying now is a spatial intersect query on every operational layer that's visible for the current map scale, with an envelope with tolerance around the mouse click. Basically this code:

var clickPoint = mouse.mapPoint;
var currentMapScale = mapView.mapScale;
var mapTolerance = 8 * mapView.unitsPerDIP;
var envelope = ArcGISRuntimeEnvironment.createObject("Envelope", {
   xMin: clickPoint.x - mapTolerance,
   yMin: clickPoint.y - mapTolerance,
   xMax: clickPoint.x + mapTolerance,
   yMax: clickPoint.y + mapTolerance,
   spatialReference: clickPoint.spatialReference
});
var queryParams = ArcGISRuntimeEnvironment.createObject("QueryParameters", {
   geometry: envelope,
   spatialRelationship: Enums.SpatialRelationshipIntersects
});
onlineMap.operationalLayers.forEach(function(fl) {
 if (fl.visible && fl.isVisibleAtScale(currentMapScale)){
  var taskId = fl.featureTable.queryFeaturesWithFieldOptions(queryParams, Enums.QueryFeatureFieldsMinimum);
 }
}

It seems to always use the local cache and total processing time is generally less than 100ms. This assumes all fields we need are in the minimum set. Other than dealing with the large # of callbacks and keeping track of tasks to know when we're done, do you see any downside to this approach?

[LucasDanzinger]

If this gets you the results you want in your testing, then that should work.

However, there are some differences between a query and an identify to consider while testing. Identify is doing an internal graphics "hit test" to see what you tapped on. For example, if it is a point, the symbol may display at a slightly different location than the feature's actual geometry. Think of a pin point picture marker symbol that might have a height of 30 pixels and have a y offset of 15. Your tolerance would need to be dialed in to account for this. You might also have different behavior at different scales. Your code example looks like it should account for this, but it is something to consider. Finally, you might also have different behavior if you have overlapping features. Identify will get the item visually on top whereas a query may have a different order. These are a few things I'd keep in mind while testing your solution. There may be other nuances I haven't considered.

[MarkHolm]

Will the ability to do an identify and return a minimum set of information be added in a future release? Avoiding the network traffic and querying the cache would be ideal for an identify.

[LucasDanzinger]

This isn't something we currently have planned. The best thing to do for logging a new feature request or enhancement is to log it through Esri Support because this will allow us to connect your customer number to the request and will also allow other organizations to be attached to the request.