Location reverse geocode bugs / improvements - any devs around?

I am inspired to write here by Reverse geocode returns null city · Issue #4828 · expo/expo · GitHub which has gone quiet. I hope that this is the right place to reach the Expo developer community - I tried Slack and it’s full of questions and few responses.

The crux of the issue is that the code here doesn’t work and can result in null fields. (Reproduced below in full…)

  return resultObject.results.map(result => {
    const address: any = {};

    result.address_components.forEach(component => {
      if (component.types.includes('locality')) {
        address.city = component.long_name;
      } else if (component.types.includes('street_address')) {
        address.street = component.long_name;
      } else if (component.types.includes('administrative_area_level_1')) {
        address.region = component.long_name;
      } else if (component.types.includes('country')) {
        address.country = component.long_name;
      } else if (component.types.includes('postal_code')) {
        address.postalCode = component.long_name;
      } else if (component.types.includes('point_of_interest')) {
        address.name = component.long_name;
      }
    });
    return address as Address;
  });

Basically in different parts of the world, the semantics of the fields returned by the API are different, so the hard mapping in the code is broken.

This is backed up by questions like this and this. According to those links, the city can be stored in any of locality, postal_town, and administrative_area_level_1, and that’s probably not all.

I’d like to work on this issue but I don’t want to submit a PR that will be rejected. I can see two ways to improve things:

  1. Try to be smart about the mapping. I think this is fragile because it relies on Expo being an expert about every potential case.
  2. Simply pass the Google result back as is, and let the client do what it wants. I like this because it’s simple and the Google API is pretty well-documented.

What do we think would be preferred? Also, in any event, we should surely provide the formatted_address field as seen in the docs. Currently if the client wants to display the full address, it must concatenate other fields, which is buggy in and of itself, even before taking the above-mentioned mapping bug into accounts.

Any devs out there with thoughts on this?

1 Like

Hi

The Expo Team has been a bit quite lately because of the holidays:

The GitHub issue is probably the best place for this. It will not be lost amongst all the other forum posts :slight_smile:

Perhaps you should post your proposal as a comment on the issue. I suspect the Expo Team would appreciate your PR after there is some agreement on what the fix should look like.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.