Select to view content in your preferred language

ServiceFeatureTable.QueryFeatureAsync changing the Spatial Relationship on the query parameters when requesting features from the service

1144
5
04-05-2022 04:34 PM
AlexGonzalez2
Emerging Contributor

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?

0 Kudos
5 Replies
JenniferNeryEsri
Occasional Contributor

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.

 JenniferNeryEsri_0-1650660654380.png

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);
    }
}

 

0 Kudos
AlexGonzalez2
Emerging Contributor

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.

0 Kudos
JenniferNeryEsri
Occasional Contributor

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).

0 Kudos
AlexGonzalez2
Emerging Contributor

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.

0 Kudos
JenniferNeryEsri
Occasional Contributor

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.

0 Kudos