POST
|
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
10-09-2020
11:44 AM
|
1
|
0
|
858
|
POST
|
Hi, Using 100.7. Scenario is user views a map extent with on interaction cache mode and then someone else deletes a feature that is in that extent. We are seeing that features which are deleted by someone else stay cached locally and visible long after the features are gone. I'm testing this scenario right now, going on about 17 hours after the feature was deleted. Newly added features or features which are moved -- those changes get picked up immediately upon slight change of the extent, but deleted features stay. Is this the expected behavior? Even identifying on that feature and the service responding that it doesn't exist doesn't remove it. Moving the map entirely somewhere else and coming back also doesn't refresh it. Just curious if this deleted feature is expected to remain indefinitely in this "on interaction cache" mode? In order to clear it would the user have to restart the application or the code would have to manually clear the cache? I think our expectation was that the cache would expire at some point. If I would adjust the cachePolicy - Enums.NetworkCachePolicy, would this change this behavior? I realize this via QML is accessible only from 100.8, which is why I haven't tried it. Thanks!
... View more
10-08-2020
09:53 AM
|
0
|
3
|
902
|
POST
|
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!
... View more
09-28-2020
02:32 PM
|
0
|
1
|
759
|
POST
|
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
09-25-2020
10:53 AM
|
0
|
1
|
2008
|
POST
|
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
09-24-2020
03:21 PM
|
0
|
3
|
2008
|
POST
|
Hi, I see that with 100.9 ArcGIS SDK is sending several requests per layer when the extent changes. We routinely test with Fiddler and immediately noticed the increase on upgrade from 100.7 to 100.9. We see this is due to this enhancement: Feature Layers now use tile-based requests to fetch and display features in a map when the underlying feature service supports this capability. Feature tiles enable ArcGIS Runtime to display more features from the service and provides faster initial load time by generalizing complex geometries for display. Feature tiles use a Protocol Buffers binary format to compress the data being transferred along with advanced HTTP caching semantics to reduce the impact of network latency and improve performance. At this release, feature tiles are not used to request features for display in a scene (3D). Is there any way to tell the SDK to use standard requests for extent queries (besides disabling the capability on the feature service)? It would be nice to either globally set a flag on the client to use standard requests and/or set it on a per layer basis. Our users routinely have minimum 50 layers visible. Instead of 50 requests when they move the map, now we might see 300 requests. If any of those layers perform poorly, the effect of poor performance compounds. Separately, I am seeing the data return in json and not "Protocol Buffers binary format" - not really an issue, just an observation. Thanks!
... View more
09-24-2020
01:12 PM
|
0
|
6
|
2149
|
POST
|
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
01-09-2020
08:10 AM
|
0
|
3
|
1036
|
POST
|
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!
... View more
01-06-2020
03:06 PM
|
0
|
5
|
1174
|
Title | Kudos | Posted |
---|---|---|
1 | 10-09-2020 11:44 AM |
Online Status |
Offline
|
Date Last Visited |
11-18-2020
04:16 PM
|