identifyLayersWithMaxResults - prioritize over extent queries?

[BrianKeller]

I had submitted a question about extent queries (Tile-based feature requests for extent - any way to revert to standard?) and wanted to follow up separately on the question about identify performance.

A typical use case of our users is following lines/features on a map to get to the endpoint where another feature exists. Then they click on that feature to load its full details. We use QML MapView identifyLayersWithMaxResults at that mouse point. It appears identify doesn't execute the object query to the server until all outstanding extent queries finish, which to the user just looks like delay when the feature they want is already visible.

James Ballard had replied on the linked post that runtime uses QNetworkAccessManager internally, which is why we are seeing HTTP requests queued. I'm assuming that identify queries are not any different and get added to the end of the queue. Is that accurate?

Is there any way to prioritize the identify queries over the outstanding extent queries?

If instead of identifyLayersWithMaxResults, we would use identify for individual layers, would it make any difference, or are they just stacked on the queue anyway?

In the past we asked whether identify could query the local cache instead of querying for the full object (How to avoid full query with identify) but the answer was not possible without using manual cache. I still think this would be a good enhancement and we will submit the feature request.

Thanks! Identify performance is one of the main issues that our users have. We get user complaints on this frequently, that identify appears to "hang" and not respond after panning the map. Please let me know if there are any options we have to improve this. Thanks!

[JamesBallard1 · Accepted solution]

Hi Brian Keller‌,

I'm assuming that identify queries are not any different and get added to the end of the queue. Is that accurate?

Correct.

Is there any way to prioritize the identify queries over the outstanding extent queries?

Unfortunately, no. Any network requests made to the same host would be subject to the same queueing behavior internally.

If instead of identifyLayersWithMaxResults, we would use identify for individual layers, would it make any difference, or are they just stacked on the queue anyway?

That is hard to definitively answer. The Runtime does do more work with identifyLayersWithMaxResults, compared to identifyLayerWithMaxResults when you know which layer the GeoElement is in. That would need to be weighed against any added overhead and data structures required to support calling identifyLayerWithMaxResults and knowing which Layer(s) to check. That is the reason we support identifyLayersWithMaxResults so you don't need to keep track, but with ~50-ish layers that could result in a lot of network traffic for the Runtime to check every layer.

So, the simple answer is that yes, if you use identifyLayerWithMaxResults it could save a lot of extra network traffic. The flipside is that that could be tricky to implement since there may be no consistent way to build such a mapping of GeoElements and the layers they belong to. See this important best practice (section Object uniqueness)

Qt SDK best practices—ArcGIS Runtime SDK for Qt | ArcGIS for Developers 

Thanks! Identify performance is one of the main issues that our users have. We get user complaints on this frequently, that identify appears to "hang" and not respond after panning the map. Please let me know if there are any options we have to improve this. Thanks!

Some options are to use Enums.FeatureRequestModeManualCache mode, but that is not always simple since users don't see the latest data without some manual refresh support.

Another option is to limit the number of layers that are visible in your map at any given time. This might make the biggest difference, especially hiding any feature-dense layers before performing an identifyLayerWithMaxResults.

https://developers.arcgis.com/qt/latest/qml/guide/qt-sdk-best-practices.htm