Inconsistency in reverse geocoding results across field app and browser

1058
4
Jump to solution
04-10-2019 09:08 AM
AaronKoelker
Occasional Contributor III

While designing a survey that takes advantage of reverse geocoding a user created geopoint to populate an address field, I'm seeing a difference in the information pulled from the default ESRI World Geocoding service depending on if I fill out the form via the field app or the browser app. See screenshots below. Both points are in the same location, and while the field app returns an address number and a street, the browser form always returns an intersection of two streets, and never an address number. Often if the geopoint is not near an intersection, the two streets returned won't even make sense. It might grab a second street hundreds of meters away or a block over, and which never intersects the first street. Or two distant streets entirely. I don't see this level of inaccuracy in the field app.

It's also not a matter of the two points having slightly different lat/lon. I'm able to reproduce this consistently, where the field app can semi-reliably return an address number and street and the browser form only gives two street names. Is this a bug, or am I doing something wrong? For this test field I'm just using < pulldata("@geopoint",${locationfield}, "reversegeocode") > and the default ESRI World Geocoder. Appreciate any help.

Survey123 Connect preview

Survey123 Browser form

Standalone Survey123 Field App on Windows

I get the same results on the Android field app that I do on the Windows field app above.

-Aaron

-Aaron
1 Solution

Accepted Solutions
ZhifangWang
Esri Regular Contributor

Hi Aaron,

Thank you for the feedback.

 This is s a known bug in the web app currently, which is caused by always passing "StreetInt" to featureType parameter. Will let you know once it's fixed.

In addition, you can input additional parameters for the pulldata reversegeocode function as a workaround, e.g.  pulldata("@geopoint",${location},"reversegeocode","","featureTypes="). In such way, the featureType will be overwrittern by a blank value and will return the default result which you expect. See https://community.esri.com/groups/survey123/blog/2018/07/06/understanding-reverse-geocoding-in-surve... for details of the additional parameters.

View solution in original post

4 Replies
ZhifangWang
Esri Regular Contributor

Hi Aaron,

Thank you for the feedback.

 This is s a known bug in the web app currently, which is caused by always passing "StreetInt" to featureType parameter. Will let you know once it's fixed.

In addition, you can input additional parameters for the pulldata reversegeocode function as a workaround, e.g.  pulldata("@geopoint",${location},"reversegeocode","","featureTypes="). In such way, the featureType will be overwrittern by a blank value and will return the default result which you expect. See https://community.esri.com/groups/survey123/blog/2018/07/06/understanding-reverse-geocoding-in-surve... for details of the additional parameters.

AaronKoelker
Occasional Contributor III

Thanks for the info Zhifang! The workaround functions like you said and will work out just fine for us. Much appreciated!

-Aaron

-Aaron
0 Kudos
JodyZhengLiu
Esri Contributor

Hi Aaron,

This has been fixed in the web app and will be available on our next release (version 3.4) late May. Would you please have a try then?

Thanks and best regards,

Jody Zheng Liu

AaronKoelker
Occasional Contributor III

Will do, thanks for the update.

-Aaron

-Aaron
0 Kudos