Use a more accurate result for Android app locality notes

Feature Requests
1

Sometimes the “locality notes” for observations made with the Android App are strange or inaccurate. For an egregious example, the locality notes on this observation https://www.inaturalist.org/observations/81739700 name a town that is nearly 200 km away. I believe I’ve found in the code exactly why this is happening.

In the code for the website, there is a simple algorithm for picking the best result from the reverse geocoder:

if ( neighborhood ) {
 locationName = neighborhood.formatted_address;
} else if ( sublocality ) {
 locationName = sublocality.formatted_address;
} else if ( locality ) {
 locationName = locality.formatted_address;
} else if ( level2 ) {
 locationName = level2.formatted_address;
} else if ( level1 ) {
 locationName = level1.formatted_address;
}

This is, I believe, the code used on the android app, which just picks the first result from the geocoder that isn’t a street address:

for (Address address : addresses) {
 if (address.getThoroughfare() == null) {
  for (int i = 0; i <= address.getMaxAddressLineIndex(); i++) {
   location.append(address.getAddressLine(i));
   location.append(" ");
  }
 break;
 }
}

At least in Ontario, this first result seems to often be an address of type “postal_code”, the names of which are not suitable as a description for an observation location. Would it be possible to update the Android app to use a similar algorithm to that on the website?

2

I think this goes beyond these code snippets, which imply it could simply be a difference in the location descriptor algorithm between Web and Android submissions.

I’ve found a fair number of examples where observations submitted using either Android or iPhone apps have location descriptors which do not match any of the options returned by the google maps reverse geocoding app when I enter the lat/long. And this doesn’t just happen in remote areas of Northern Ontario.
Here’s an example:
https://www.inaturalist.org/observations/216162280

3

I would venture to call this a bug/deficiency rather than a feature request.