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

Question

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={"xmin":-10862928.215694556,"ymin":6103526.6903118202,"xmax":-10862918.214113874,"ymax":6103536.6918925019}&geometryType=esriGeometryEnvelope&inSR=3857&maxAllowableOffset=0.5&outFields=*&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={"xmin":-10862793.19435535,"ymin":6103651.7100703456,"xmax":-10862783.192774668,"ymax":6103661.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?

JenniferNery · Answer

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.

AlexGonzalez2 · Answer

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.

JenniferNery · Answer

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