ServiceFeatureTable.populateFromService silently returns 0 features when returnGeometry=false + spatial filter

[BenHaas4]

Summary

In FeatureRequestMode.ManualCache, ServiceFeatureTable.populateFromService(...) with a spatial predicate (geometry + spatialRelationship) silently drops every server-returned feature when returnGeometry = false. The SDK appears to re-apply the spatial filter locally against the just-cached rows; those rows carry null geometry because the SDK itself requested returnGeometry=false; a local intersects(envelope, null) returns false for every row, so the cache evaluates to empty even though the server replied with the correct features. No exception, no log warning.

Is this expected behavior? In my case, I don't need the geometry for the features returned from the intersect. 

[Nicholas-Furness · Accepted solution]

Hi @BenHaas4.

Sorry for the delay getting back to you.

Assuming you are setting returnGeometry=false on the QueryParameters being used to populate the table (I think you are), then I would expect this behaviour, yes, though arguably we should treat this as an error and provide better feedback.

What you have with a ServiceFeatureTable from a feature layer (i.e. NOT a non-spatial table) is a table that expects a geometry as part of its schema. It's reading the feature service definition to get to that state. So the geometry field cannot be NULL in this table, but you're trying to populate the table with NULL geometries.

When you then try to populate it with geometry-less features, what should it do¹? It's an invalid state for that feature table to have records with no geometry.

You could do one of two things:

1. Don't populate the table manually. Instead use the default featureRequestMode (onInteractionCache) and then simply query (not populate) the ServiceFeatureTable using the QueryParameters. That will return you a dataset of the features you want, without their geometries.
2. Populate the service feature table including the geometries, but then ignore the geometries when you work with the features you get back.

Hope that helps. Let me know if I've missed something.

---

¹ Well, what it should probably do is tell you that you can't do what you're trying to do, not nothing at all and leave you hanging… I'll see if we can look into that. Feels like a decent improvement to the SDKs.

[BenHaas4]

Thanks @Nicholas-Furness , that makes perfect sense now that I'm not in the middle of troubleshooting. I agree that an error state would be an improvement over the silent failure. Thanks for the quick reply.