I've run into a strange issue with the use of ServiceFeatureTable.QueryFeaturesAsync() in .Net Runtime 100.13.
I currently have some code that looks like this:
QueryParameters parameters = new QueryParameters
{
Geometry = selectionGeometry,
SpatialRelationship = SpatialRelationship.Intersects,
ReturnGeometry = true,
OutSpatialReference = new SpatialReference(102100),
MaxAllowableOffset = 0.5
};
return await ServiceFeatureTable.QueryFeaturesAsync(parameters, QueryFeatureFields.LoadAll);
And if the selectionGeometry is an envelope the request coming out of the application in Fiddler is changing the spatial relationship in the request to esriSpatialRelEnvelopeIntersects instead of submitting it as esriSpatialRelIntersects. This is causing issues becuase it is returning too many features.
This is what the request coming out of the application looks like. (paths omitted due to sensitive data):
GET https://portalserver/rest/services/FeatureLayer/MapServer/0/query?f=json&geometry=%7B%22xmin%22%3A-10862928.215694556%2C%22ymin%22%3A6103526.6903118202%2C%22xmax%22%3A-10862918.214113874%2C%22ymax%22%3A6103536.6918925019%7D&geometryType=esriGeometryEnvelope&inSR=3857&maxAllowableOffset=0.5&outFields=%2A&outSR=3857&returnDistinctValues=false&returnGeometry=true&returnM=true&returnZ=true&spatialRel=esriSpatialRelEnvelopeIntersects
If I change the query to use PopulateFromServiceAsync like this:
return await ServiceFeatureTable.PopulateFromServiceAsync(parameters, false, new List<string> { "*" });
The request that comes across in Fiddler with a SpatialRelationship set to esriSpatialRelIntersects and executes appropriately.
This is what that request looks like in Fiddler:
GET https://portalserver/rest/services/FeatureLayer/MapServer/0/query?f=json&geometry={%22xmin%22%3A-10862793.19435535%2C%22ymin%22%3A6103651.7100703456%2C%22xmax%22%3A-10862783.192774668%2C%22ymax%22%3A6103661.7116510272}&geometryType=esriGeometryEnvelope&inSR=3857&maxAllowableOffset=0.5&outFields=*&outSR=3857&returnDistinctValues=false&returnGeometry=true&returnM=true&returnZ=true&spatialRel=esriSpatialRelIntersects
The issue is the performance of that method is much slower than QueryFeaturesAsync due to skipping the local cache. So I need to be able to use QueryFeaturesAsync.
Is there some way I can get QueryFeaturesAsync to request the correct spatial relationship? Or is this a runtime bug?
Hi Alex,
I'm not able to reproduce query sending the wrong spatial relationship on 100.13 and latest. I have the following code based on your query parameters. Could you may be looking at the query made from panning/zooming the map where it needs to get more features in the view extent? I added ArcGISHttpClientHandler.HttpRequestBegin event to interrogate query URL.
public MainWindow()
{
InitializeComponent();
MyMapView.Map = new Map(new Basemap(new OpenStreetMapLayer()));
MyMapView.Map.OperationalLayers.Add(new FeatureLayer(new Uri("https://sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/0")));
}
private async void OnQuery(object sender, RoutedEventArgs e)
{
try
{
var geometry = await MyMapView.SketchEditor.StartAsync(Esri.ArcGISRuntime.UI.SketchCreationMode.Rectangle, false);
var query = new QueryParameters() { Geometry = geometry, SpatialRelationship = SpatialRelationship.Intersects, ReturnGeometry =true, OutSpatialReference = MyMapView.Map.SpatialReference, MaxAllowableOffset=0.5 };
var layer = MyMapView.Map.OperationalLayers[0] as FeatureLayer;
ArcGISHttpClientHandler.HttpRequestBegin += (a, b) =>
{
if(b.RequestUri?.OriginalString.Contains("/query") == true)
{
MessageBox.Show(b.RequestUri.OriginalString,"query", MessageBoxButton.OK);
}
};
await (layer.FeatureTable as ServiceFeatureTable).QueryFeaturesAsync(query, QueryFeatureFields.LoadAll);
}
catch (TaskCanceledException)
{
}
catch(Exception ex)
{
MessageBox.Show(ex.Message, ex.GetType().Name, MessageBoxButton.OK);
}
}
Hi Jennifer,
I was able to solve the issue by converting my geometry to a point for the time being. But, I did talk to someone named Wesley through chat support and they were able to reproduce the issue and logged it as BUG-000148414. So I have a solution for the time being.
Thanks, Alex for sharing the issue number. The difference between our repro samples is - the rectangle drawn by SketchEditor is a Polygon type so it remains SpatialRelationship.Intersects in the request. Whereas, if I use the extent of this geometry, an Envelope type, the request issued becomes SpatialRelationship.EnvelopeIntersects. This is by design to accommodate ArcGIS server optimizations available only for Envelope type that is not present in its functionally-equivalent counterpart (SpatialRelationship.Intersects).
Sure, that makes sense. I feel like it should be documented somewhere in the documentation so that it's more clear to developers on what the expected behavior is.
What happened was we upgraded from 100.7 to 100.13 and somewhere along the line that caused an issue to surface where we were converting a point to an small envelope and using that to get intersecting features.
What was happening was the query started returning many more features than expected due to the change in spatial relationship on that call. So this caused a bug in our software. We've corrected the issue now. But there was no information conveyed, that I could find, on when or why the changes were made.
Thanks for your feedback and apologies for the inconvenience this caused. We'll try to improve our docs and release notes for behavior changes like this. I was not aware the change in spatial relationship for this geometry type yielded very different result.