Specify outFields in Quartz

2172
6
11-27-2016 11:36 AM
JamesRichards1
Occasional Contributor

Can we specify the outFields when querying a server based feature layer in Quartz?

At 10.2.5 - the AGSQuery object had an outFields property which took a list of fields and mapped them to the REST API outFields parameter.

In Quartz 10.0, the AGSQueryParameters object does not have an outFields property.

The AGSServiceFeatureTable object does have a method called queryFeaturesWithParameters:fields:completion: but the fields parameter takes an enum with only three options: 

- AGSQueryFeatureFieldsIDsOnly
- AGSQueryFeatureFieldsMinimum
- AGSQueryFeatureFieldsLoadAll

Is there some other way to specify the out fields when querying against the ArcGIS Server REST API?

6 Replies
SuganyaBaskaran1
Esri Contributor

hello, 
Yes, AGSQueryParameters no longer has outFields. You can use one of the AGSQueryFeatureFields enum values or use the service feature table in ManualCache mode which allows specifying outFields

The concept of loading features into tables in 100.0.0 is different from 10.x where all the fields were brought by default and features were in memory, so you could use outFields to easily get a subset of fields. 

100.0.0 featureRequestMode OnInteractionCache:

In 100.0.0, the default featureRequestMode of AGSServiceFeatureTable (OnInteractionCache) brings down just the minimum set of fields required for rendering of features on map in addition to any editor tracking fields. This enables rendering and working with large number of features with just necessary fields to start with, without the overload of fetching everything. A feature could then be loaded to get all fields as needed, for instance when beginning to edit. 

When querying a table in this mode, you can request for 
- IDs only 
- Minimum fields required for rendering (which is what happens when the layer is added to a map)
- Load all features which means all fields are queried

 

The query in this mode could be local or an online query depending on whether the features are already in the table and the AGSQueryFeatureFields enum chosen. 

100.0.0 featureRequestMode ManualCache:

If you set featureRequestMode on the table to ManualCache, it means the features would be populated from the server once, and would be used locally there forth, likely in a disconnected environment. You can specify outFields then while populating using the method populateFromServiceWithParameters:clearCache:outFields:completion:

Note that querying is always local in Manual Cache mode. 

JamesRichards1
Occasional Contributor

Hi Suganya, Thanks for your answer. Followup question: When using the method populateFromServiceWithParameters:clearCache:outFields:completion:

is it subject to the maxRecordCount limit?

0 Kudos
SuganyaBaskaran1
Esri Contributor

James, 
Yes, it is. You can check AGSFeatureQueryResult's transferLimitExceeded.

We have plans to add support for paging queries in an upcoming release

Suganya

0 Kudos
MichaelDavis3
Occasional Contributor III

Would it be correct to assume that this applies to queries from a local geodatabase as well?

What will be returned by AGSQueryFeatureFieldsIDsOnly? 

This all or nothing approach to returning fields has the potential to create some significant unnecessary memory usage or slowdown when querying large volumes of data.  It was great to be able to minimize the fields returned to only those needed for the current analysis/task.

0 Kudos
SuganyaBaskaran1
Esri Contributor

Would it be correct to assume that this applies to queries from a local geodatabase as well?

Queries in a local geodatabase are always local. The query therefore returns all the fields that are in the geodatabase (loaded feature)

What will be returned by AGSQueryFeatureFieldsIDsOnly? 

Unloaded features that have ObjectID and GlobalID fields will be returned

This all or nothing approach to returning fields has the potential to create some significant unnecessary memory usage or slowdown when querying large volumes of data

It's not really all or nothing.

If you want the features on the map, it must have the required fields for rendering and editing. That's the minimum set of fields returned using AGSQueryFeatureFieldsMinimum. In this case, features are loaded as needed. 

If the features won't be on the map, then you can just request for IDsOnly if the number of features is going to be more. or simply LoadAll

You could use ServiceFeatureTable's ManualCache mode to specify custom outfields. 

Let us know if your requirement still necessitates outFields

0 Kudos
MichaelDavis3
Occasional Contributor III

Our users frequently do a lot of their work outside the traditional map view.  We often use a list view (UITableView) that will let the user browse collected data, generally by date.  An example (communication log from a marine mammal observation app) is below:

This list might return anywhere from 1-5000+ entries long, depending on specified date ranges or other limiting factors.

In Runtime 2.5 and earlier we can specify exactly which fields we want to pull in the query to minimize the time it takes to run.  Over the years we've found that this can shave seconds off the response time with large data sets.

An IDs-Only query wouldn't return enough information to create this list view, and regardless we were burned enough by GlobalIDs and ObjectIDs in the past that we've standardized on using our own GUID fields to maintain relationships.

All of our apps are built to work primarily offline so we are only looking at interacting with a sqlite .geodatabase, not feature services.

Thanks!