Trouble manually inputting address when reverse geocoder not accurate

[JaredRyan1]

After using a locally hosted locator view from the Geocoding Service for nearly 2yrs, we recently started experiencing behavior where our field users try to manually input an address and the survey does not capture their input. Instead it reverts the address back to NULL. 

Most of the time the user is able to manually input their address info when outside of cellular reception and/or the reverse geocoder works as expected when able to login.

This behavior appears to be sporadic. 

The users were able to get their manual input to 'stick' after trying 6-8 times. 

Could this be a connection issue? Is this a known behavior?

Thoughts??

[Anonymous User]

Hi @JaredRyan1 

Can you confirm what version of Connect and field app you are using, and on what OS you had this issue, or does it happen on all OS and devices? Also are you using ArcGIS Online or Enterprise?

Please share your XLSForm (xlsx file and any associated media files) so we can take a closer look at how you have configured your survey?

Note that geosearch and reverse geocoding only works when the device is online (has network connection) and connection to company portal.

You can find a link to documentation here for Survey123 and reverse geocoding:

https://doc.arcgis.com/en/survey123/desktop/create-surveys/geopoints.htm#ESRI_SECTION1_E89036D9C34D4...

Regards,

Phil.

[JaredRyan1]

Phil,

I've updated my post to be more clear.

The Connect version is 3.13.244B for Windows. It could've possibly been the version before. 

The Field app version is 3.12.277 on ios.

We are working within an Enterprise environment.

We've verified the users are added to the necessary groups and have access. 

I've attached a copy of the survey here for you. 

[Anonymous User]

Hi @JaredRyan1,

I had a look at the XLSForm, and did some testing, and can reproduce the issue you have reported.

The issue occurs when the device is offline and returns to online while the form is open. If the network state changes, the pulldata() calculation will be triggered as it contains a reverse geocode request that can only be completed when online, so it is waiting for connectivity. The values in the input box get updated at this point. The network request can take some time, so the value gets cleared out (becomes null) and waits for the updated value. If during this process the network drops out again, the value returned will be null, as it never gets a response from the server. This will likely happen in areas of sporadic network connectivity.

The problem is that you are using the calculation for pulldata() and reverse geocode in an input text box that you also want the user to manually type into. This is not best practice, as will lead to the above issues and possible loss of values when calculations get retriggered on network status changes.

The best practice is to put your pulldata() reverse geocoding calculations into hidden fields, so that no matter what the result is, those fields always match the reverse geocoding result. If the device is offline, they will always be null, if the device is online they should have an address if the network is available, or update once the network comes online. You could also make these questions read only, not hidden (or use a note question type), so the user can see the results but not edit them.

Then have additional text fields that are available to the user for manual address entry, so that they can manually type an address when the above fields are null. To make this smarter you could use relevant statements or use an if() statement to display the geocoded address when it exists, into that same field, and allow manual entry if it needs to be updated. You could then combine these two fields into the one final field that is stored in the feature layer and dont store the other fields, unless you really want to. Using the two different fields for the calculation and manual input will solve the above issues when network status changes.

Has this always been an issue, or is it new to 3.12 release or another version of the app? Or is it only newly reported by users now working in sporadic network locations? The reason I ask is that over recent releases there have been improvements to networking and the online/offline status, and ensuring that network requests can be triggered and completed when the network status changes while the app is open. There were bugs previously that stopped this happening, and you had to restart the app when network changed. It could be possible these improvements now affect your survey, as you are using the same field for both the calculation and manual input of the address.

Regards,

Phil.

[Anonymous User · Accepted solution]

Hi @JaredRyan1,

Here is an example of how you can get it to work with some additional feilds and logic:

XLSForm example attached below. You would want to make different fields hidden or read only to simplify it for the user, but you hopefully this helps.

I tested this both online and offline and works as expected. If there is a manually entered address it will always be used, if there is no manually entered address, the reverse geocode address is used. If you are offline and then go online, and have already entered manual address, the geocoded addresses get updated, but doesn't affect the manually entered addressed stored in the final address fields.

Regards,

Phil.

[JaredRyan1]

Thank you, @Anonymous User. I'm glad you could replicate it, and your fix is easy enough.

As far as I know, we've only recently in the last 3-4 weeks seen this happen. With that being said, we're seeing the heaviest use of the survey that we've ever had. So maybe it was always doing it, just not often enough to be called out.