Latest Contributions by BrianKeller

James Ballard‌, refreshInterval looks to be a good option for clearing out these stale features. Tested it and it works well. Now just have to find the right interval. I think using this would be sufficient and we don't have to go all the way to Enums.FeatureRequestModeOnInteractionNoCache, but I will play with it. Thanks! ... View more

James Ballard‌, I'm getting the impression that the extent query by tiles is not configurable and that it's considered better generally. I understand that it has some benefits. By breaking the extent requests into tiles, you can get more features in smaller chunks - potentially exceeding the normal maxRecordCount. This makes a lot of sense for dense features or zoomed out map scales. I do see some tile queries getting HTTP 304 Not Modified as I pan around, which I don't think I ever saw with the standard implementation - so there is no data transfer and it uses cache. Awesome! Many of my layers are only visible between max scale 0 and min scale 2000. My features are not that dense at those scales and I rarely worry about maxRecordCount. In my testing, I've been right around 1:500 scale. Most of the extent queries are returning empty results or very small results. The payloads are so variable that it's hard for me to compare unless I setup some automated movements of the map between versions, which I can do. I'm not concerned about the data size. What concerns me is the overall request count and the total time it takes for those requests to complete. Each layer is generally returning in 80-100ms. When I do one swipe of the map at this scale on 100.7, I measured about 600-800ms for approximately 50 layers to load that new extent. When I did the same in 100.9 showing approximately 6 times the # of requests, it was between 2.6 and 4.7 seconds. I just did a few rounds of this, not super scientific. I'm guessing this is because the requests don't all fire simultaneously. There seems to be some queueing or batching taking place. This can add up fast! Especially if the user is panning around or zooming. And way worse if any layer along the way takes longer to respond, it seems to hold up the requests. (Side note, I would love to know how HTTP requests are queued or batched with the Qt runtime and if this is configurable.) One of the issues I see with extent requests overall taking longer because there are more of them, is that it seems an identifyLayersWithMaxResults call waits for them all to finish. If the user finds feature(s) they want to identify after panning, it just seems to hang there while all of these background extent requests finish. Maybe it gets added to the end of the queue or maybe it's purposefully waiting for the extent queries. How can I get the identify to fire/return immediately? I had asked whether the full object query can be skipped before (How to avoid full query with identify ) but the answer was not possible. So would it make sense to prioritize the identify queries over the extent queries? I can open another question for this - it likely deserves a separate thread of conversation. We get user complaints on this frequently, that identify appears to "hang" and not respond after panning the map. This is my main concern in general, even in 100.7, but it is worse with the tile queries. Would it make sense to set some minimum size for tiles, so that as you zoom in, you're not still splitting an already small extent into multiple tiles? In my testing the extent queries are taking longer to finish because there are more of them. This directly impacts the user's ability to identify quickly after panning. If we're not able to turn off tile requests or get them to finish in the same amount of time as standard extent queries, I don't think we will be upgrading. I will continue to do testing and comparison, but would love to see this configurable or discuss other options. Thanks! ... View more

Hi James, thanks for the reply. Our feature services report: "supportsCoordinatesQuantization": true, "supportsQueryWithResultType": true, but also (maybe this is related?) "supportedQueryFormats": "JSON, geoJSON" We do not set FeatureRequestMode, and I think by default it uses OnInteractionCache, right? We use QML, and I did set featureRequestMode: Enums.FeatureRequestModeOnInteractionCache just to test - I see no change in the number of queries. I fired up the 100.7 app and 100.9 app to see the parameters being sent. Approximately 6 queries per layer on 100.9 on a swipe of the map to the right, with just 1 query in 100.7. Example parameters below, removed outFields 100.7: f json geometry {"xmin":-9754688.5980574563,"ymin":5144905.825081734,"xmax":-9754285.8681001626,"ymax":5145158.4307802767} geometryType esriGeometryEnvelope inSR 3857 maxAllowableOffset 0.000000 outSR 4326 returnDistinctValues false returnGeometry true returnM false returnZ true spatialRel esriSpatialRelEnvelopeIntersects 100.9: f json geometry {"xmin":-9754664.2386693377,"ymin":5144976.3738752119,"xmax":-9754587.8016410526,"ymax":5145052.810903497} geometryPrecision 0 geometryType esriGeometryEnvelope inSR 3857 outSR 4326 quantizationParameters {"mode":"view", "originPosition":"upperLeft","tolerance":0.000000083913137,"extent":{"type":"extent","xmin":-13829886.018444981426001,"ymin":2665722.322176279034466,"xmax":-7187861.637385762296617,"ymax":8600914.461163187399507}} resultType tile returnDistinctValues false returnExceededLimitFeatures false returnGeometry true returnM false returnZ true spatialRel esriSpatialRelEnvelopeIntersects Wouldn't by nature resultType = tile send more requests? I was reading here about the differences in what that means: Query (Feature Service/Layer)—ArcGIS REST API | ArcGIS for Developers  Thanks ... View more

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? ... View more