Types for Google Maps JS Autocomplete don't return the same address_components

Question

I'm using google.maps.places.Autocomplete to attach autosuggest address/city to an input field. We need to support both full addresses and cities, so I use the types of ["street_number", "street_address", "route", "locality"], but we had some complaints that some of the addresses weren't correct. I dug into and was able to replicate the issue. I first changed the types to just be ["address"] and then everything worked as expected.

What I found is there is a missing address_component when using ["street_number", "street_address", "route", "locality"] vs ["address"].

Google maps version: 3.55.4

I have created a fiddle for the following here

Steps to replicate the issue:

1. Select "address" option
2. Enter "10800 I-27, Amarillo, TX 79119"
3. Select the first result from the autosuggest
4. Look at the console and look at the "address_components" section, which there will be 8 listed
5. Select the "street number" option
6. Enter the same address from step 2 above
7. Look at the console and look at the "address_components" section, which there will be only 5 with "street_number" missing

// This is using types of ["address"]
[
    {
        "long_name": "10800",
        "short_name": "10800",
        "types": [
            "street_number"
        ]
    },
    {
        "long_name": "Interstate 27",
        "short_name": "I-27",
        "types": [
            "route"
        ]
    },
    {
        "long_name": "Amarillo",
        "short_name": "Amarillo",
        "types": [
            "locality",
            "political"
        ]
    },
    {
        "long_name": "Randall County",
        "short_name": "Randall County",
        "types": [
            "administrative_area_level_2",
            "political"
        ]
    },
    {
        "long_name": "Texas",
        "short_name": "TX",
        "types": [
            "administrative_area_level_1",
            "political"
        ]
    },
    {
        "long_name": "United States",
        "short_name": "US",
        "types": [
            "country",
            "political"
        ]
    },
    {
        "long_name": "79119",
        "short_name": "79119",
        "types": [
            "postal_code"
        ]
    },
    {
        "long_name": "2526",
        "short_name": "2526",
        "types": [
            "postal_code_suffix"
        ]
    }
]

// This is using types of ["street_number", "route", "locality"]
// I even tried types of ["street_number", "route", "locality", "street_address"]
[
    {
        "long_name": "Interstate 27",
        "short_name": "I-27",
        "types": [
            "route"
        ]
    },
    {
        "long_name": "Amarillo",
        "short_name": "Amarillo",
        "types": [
            "locality",
            "political"
        ]
    },
    {
        "long_name": "Potter County",
        "short_name": "Potter County",
        "types": [
            "administrative_area_level_2",
            "political"
        ]
    },
    {
        "long_name": "Texas",
        "short_name": "TX",
        "types": [
            "administrative_area_level_1",
            "political"
        ]
    },
    {
        "long_name": "United States",
        "short_name": "US",
        "types": [
            "country",
            "political"
        ]
    }
]

I have added the type of "street_address" to see if that would help, but it hasn't.

I'm not sure what I'm missing here and why it works with "address" over the individual parts.

Answer 1

The API is working as intended if it did not return the same component when changing types

I'd like to quote geocodezip above for his findings on the comments as reference of this answer:

If you look at the place_id of the returned place in those two cases, it is different

• address: ChIJoRDdoxRbAYcRhC4lmbBCsqA,
• street number: EhdJLTI3LCBBbWFyaWxsbywgVFgsIFVTQSIuKiwKFAoSCdHTE43skwGHEdaA1x2Hvso0EhQKEgkDz0Wy1EgBhxGv0jZoHNHz0A

As you have noticed, when changing the types for the search into street_number, it returns a very long place_id. This could mean that the returned result was a Synthetic Address when changing the types.

As explained by the Google Maps Platform documentation,

The Geocoding API may return locations for "synthetic" addresses that don't exist as precise locations in Google’s database.

In such scenarios the response object often contains a long Place ID.

Since the Places API uses Geocoding API to a certain extent, this could only mean that a street address for 10800 I-27, Amarillo, TX 79119 does not exist and the API tried its best to provide an approximate location.

I tried looking further but the address 10800 I-27, Amarillo, TX 79119 was an actual address with types as premise.

So it would make sense that if you try to search this specific address as a street address or route, the API would not find it in it's database, so it makes an approximate location of a "route" as a Synthetic Result.

As mentioned by the Address Validation documentation,

"If you encounter these indicators in the response, please consider marking the input address as an invalid and try to re-validate it by another means."

If your use case needs you to have a valid address, I'd suggest you use Address Validation API or just use the address types to return specific addresses instead of routes.