search() appearance functionality using feature service, searches on end of string instead of front.

[AbeCoughlin]

Using the search() appearance functionality to fill a drop-down list from a feature service successfully loads data from the feature service (it shows correctly in an ordered manner)..., BUT, when typing in values, it is matching it to the end of the string, not the beginning.

The data is address data. So typing '201' for '201 N Broadway' should show all suggestions beginning with  201, BUT, it pulls in addresses like 1 Holland Gln, Unit 201.

I have tried the 'startswith' parameter to no avail (do the 'startswith, endswith work with spatial tables - the documentation is written that it doesn't).

Assistance please. thanks.

[AbeCoughlin]

Replying to my own text as even though I thought it made sense..., it didn't seem to read well this morning.

---

@AbeCoughlin wrote:

Using the search() appearance functionality to fill a drop-down list from a feature service successfully loads data from the feature service (it shows correctly in an ordered manner)..., BUT, when typing in values, it is matching it to the end of the string, not the beginning.

---

This should be:

Using the search() functionality to fill a drop-down list with data from a feature service, I was able to see the data from the feature service in the drop-down choices. However, when typing in values to the text field, the suggestions being returned match the end of the string, not the beginning.

Try it out for yourself: https://arcg.is/18XG8e

Looking at the results, I see 512 items in the list. Is there some feature service limitation I'm not aware of? I'm sure that this is the issue considering the list starts off exactly like that of the CSV method. I've looked at the documentation for the AGOL API but don't see any such limit, and the documentation for the AGOL Search doesn't have any matching parameters with such limitations. Same goes for the documentation for AGOL Query.

[AbeCoughlin]

Here I go replying to myself again..., I guess that's pretty much normal!

I thought I'd tweak the example survey I had above so it would now include the new Address type question with the 'geocode' appearance option. It works..., pretty nicely, maybe a tad slower than the CSV and FS?

Try it out for yourself: https://arcg.is/18XG8e

I've attached the XLSForm for review.

[ahargreaves_FW]

@AbeCoughlin  this example was handy for helping me realise how to set an 'appearance' on a search against a FS.

Thanks!

[AbeCoughlin]

A solution to the limited number of results returned: the maxRecordCount parameter for the service has to be increased. To do so, follow the instructions in this post.

The maxRecordCount parameter was determined to be the issue by using the web browser developer tools to see what data was being loaded. The feature service approach loads all records in the feature service (up to the maxRecordCount limit) into a json object WHEN the page is loaded. This means that the search() functionality via the Feature Service is not a live query and thus if all records are NOT loaded into the json object when the survey page is loaded then the value being searched for may not be included into the search results.

The outcome of this is a increased lag time for the search tool. It is not as responsive as searching on the CSV file.

Note that I'm still working on having the search() functionality to match the search term with the beginning of the data values, e.g. 201, should bring up addresses beginning with 201, and not ending in 201.

[AbeCoughlin]

In regards to the search() functionality being able to match the search term to the beginning of the data values, I've been advised through my reps (who spoke with the Survey 123 team/develoopers) that the 'startswith' capability is NOT functional currently. It seems that this is the case not only for the feature service approach but also the CSV approach. Issue resolved.

[AbeCoughlin · Accepted solution]

In order to post a full solution, I summarize my findings here:

When using a feature service as the source of records in a 'search()' appearance option, the dataset is pulled into a JSON object that is then searched when the user opens the drop-down list or starts typing (if 'autocomplete' is included in the appearance column).

If the maxRecordCount on the map service is not large enough to allow all records to be ingested into the JSON object, the drop-down list will only show the maxRecordCount of records, thus not the full list of records. Similarly, if 'autocomplete' is included in the appearance column, the matching of the search term to the records will be limited to only the records that were brought across to the JSON object.

The searchType parameter does not work. Thus, the search term that you enter into the search field (if you have autocomplete included in the appearance column) will be matched to any text within the records, e.g. searching for '201', will return both '201 N Broadway' as well as '100 N Broadway, Unit 201'. However, the records will be returned in the order in which they are stored in the database table, i.e. if the records are stored alphabetically (as I have them) then '100 N Broadway, Unit 201' will be returned before '201 N Broadway' is.

[ahargreaves_FW]

@AbeCoughlin have any thoughts on how to filter the search results? I can't figure out how to implement a cascading selecting against search results to narrow down the list....

[AbeCoughlin]

Unfortunately no directly from the Feature Service. Until ESRI improves/fixes the additional parameters to allow improved searching via a web feature service. The only work-around I would consider is to set the filter on the URL and use separate URLs for each (untested).

And, as I'm writing this, I'm recollecting that all the data gets copied to a local json object, and if that is the case, possibly you can create a new row in the Connect spreadsheet that can be used to filter the data that is in that downloaded json object. Just an idea.

[ahargreaves_FW]

---

@AbeCoughlin wrote:

...all the data gets copied to a local json object, and if that is the case, possibly you can create a new row in the Connect spreadsheet that can be used to filter the data that is in that downloaded json object.

I can't filter on the URL directly, as that's set in the choices tab of the survey. But I am interested in what you say here. But I have no clue how to even begin to do what you mention. Is there an example anywhere that you, @IsmaelChivite , @JamesTedrick or @Anonymous User  can point me towards?