Help with bug in queryFeaturesWithParameters:completion: (AGSFeatureTable) using extent, not geometry

4119
6
05-08-2020 06:20 PM
JakeShapley
New Contributor III

Hi,

I would appreciate help on Esri Case #02552078, escalating a hotfix for a bug in queryFeaturesWithParameters:completion: (AGSFeatureTable) that is present in 100.8.0. I recently refactored our Android and iOS apps to support querying stacked geometry for features that intersect or overlap a user-selected (via tap) feature. It is working properly (and as intended according to the documentation) in Android. However, in iOS, the query method appears to be incorrectly using the extent of the geometry, rather than the geometry itself. For example, a query using the Deschutes River returns, among 100s of other results, Packwood Creek, which isn't even in the same drainage. But, it is within the extent of Deschutes River (see screenshots below).

For clarification, I am using:

params.spatialRelationship = AGSSpatialRelationship.intersects

params.maxAllowableOffset = 0

I would appreciate a hotfix for this issue, plus any workaround in the meantime. I am happy to provide additional info. I cannot share the endpoints publicly, but they are attached to the case and I can provide them via DM or email.

Cheers,

Jake

Deschutes River selected in the app. Note, the location of the town of Yelm and other features for reference.

Packwood Creek selected. It is in an entirely separate drainage than the Deschutes River.

The spatial query results for Deschutes incorrectly include Packwood Creek and hundreds of others.

0 Kudos
6 Replies
Nicholas-Furness
Esri Regular Contributor

Hi Jake. I'll try to create a repro for this and will get back to you if I have trouble reproducing it.

Did this happen in 100.7 too, do you know?

0 Kudos
JakeShapley
New Contributor III

Hi Nick,

Thank you for the quick response. Yes, it was behaving the same all the way back to 100.2.1. I incrementally updated the SDK from 100.2.1 on Friday. I was guardedly optimistic that it would be resolved at 100.5.0, due to all the reworking of the queries, but no luck. I also wanted to mention that I verified the geometry I get from the tapped feature is a polyline, not an extent just before I assign it to the params.geometry; same with the params.geometry if I read it just before it is passed in the query. So, I'm pretty sure the issue is with the method itself, or the AGSSpatialRelationship enum. I can see the corresponding int values in iOS, but not Android.

Cheers,

Jake

0 Kudos
JakeShapley
New Contributor III

Also, here's a screenshot of what happens when I programmatically select the features returned from the database query (with Deschutes River still selected). Note, the river geometry does not actually intersect with any of these features.

Selection of spatial query results, with Deschutes River still selected. Note, there is no intersection of the Deschutes and any of these features.

Jake

0 Kudos
JakeShapley
New Contributor III

Hi Nick,

I rendered the ereg feature layer red temporarily to better visualize what may be happening. Interestingly, 682 features are returned by the query, all of them are within the extent. However, not all of the features within the extent are returned by the query.

Ereg features rendered in red to help visualize the issue.

Jake

0 Kudos
Nicholas-Furness
Esri Regular Contributor

Thanks Jake. These are helpful. You might not be getting all the items returned if they exceed the maxResultCount on the service. I'll have time to look into this today.

0 Kudos
Nicholas-Furness
Esri Regular Contributor

Jake Shapley: Just to confirm, this will be fixed in 100.9, due for release very shortly.

Thanks for providing all the details and helping us identify the issue.

0 Kudos