Google Geocoding XML response removes apartment/suite numbers

Question

When using the Geocode API it seems that any embedded apartment or suite number in the original address is removed in the XML response. This makes it impossible to use the returned address as a "corrected" or "standardized" format to save.

1. Is there a way to preserve the address information?

2. Secondly, as in this case, the "apt B" represents a distinct building from "A,C,D,E, etc." and hence a different rooftop geocode.

Any help appreciated

Sending the following address: 1135 Thomas Ln. Apt B, Hixson, TN 37343 to the following URL (key removed) "https://maps.googleapis.com/maps/api/geocode/xml?address=[ADDRESS]&key=[KEY]"

results in the following response:

<?xml version="1.0" encoding="UTF-8"?>
<GeocodeResponse>
 <status>OK</status>
 <result>
  <type>street_address</type>
  <formatted_address>1135 Thomas Lane, Hixson, TN 37343, USA</formatted_address>
  <address_component>
   <long_name>1135</long_name>
   <short_name>1135</short_name>
   <type>street_number</type>
  </address_component>
  <address_component>
   <long_name>Thomas Lane</long_name>
   <short_name>Thomas Ln</short_name>
   <type>route</type>
  </address_component>
  <address_component>
   <long_name>Hixson</long_name>
   <short_name>Hixson</short_name>
   <type>neighborhood</type>
   <type>political</type>
  </address_component>
  <address_component>
   <long_name>Chattanooga</long_name>
   <short_name>Chattanooga</short_name>
   <type>locality</type>
   <type>political</type>
  </address_component>
  <address_component>
   <long_name>Hamilton County</long_name>
   <short_name>Hamilton County</short_name>
   <type>administrative_area_level_2</type>
   <type>political</type>
  </address_component>
  <address_component>
   <long_name>Tennessee</long_name>
   <short_name>TN</short_name>
   <type>administrative_area_level_1</type>
   <type>political</type>
  </address_component>
  <address_component>
   <long_name>United States</long_name>
   <short_name>US</short_name>
   <type>country</type>
   <type>political</type>
  </address_component>
  <address_component>
   <long_name>37343</long_name>
   <short_name>37343</short_name>
   <type>postal_code</type>
  </address_component>
  <address_component>
   <long_name>3744</long_name>
   <short_name>3744</short_name>
   <type>postal_code_suffix</type>
  </address_component>
  <geometry>
   <location>
    <lat>35.1448870</lat>
    <lng>-85.2471100</lng>
   </location>
   <location_type>ROOFTOP</location_type>
   <viewport>
    <southwest>
     <lat>35.1435380</lat>
     <lng>-85.2484590</lng>
    </southwest>
    <northeast>
     <lat>35.1462360</lat>
     <lng>-85.2457610</lng>
    </northeast>
   </viewport>
  </geometry>
  <partial_match>true</partial_match>
 </result>
</GeocodeResponse>

Answer 1

Yes, but neither XML nor JSON know the difference between UNIT B and APT BBBB. They just echo the unit-I-D, and that regardless of the unit type. What would be helpful is a geocoding API that would return the unit type, if given a unit-I-D. For example, put in "100+Biscayne+Ave+B+33606 and get back the formatted address "100 Biscayne Ave Apt B, Tampa, Florida 33606"

Answer 2

If you can request a json response instead of an xml response, it preserves the 'Apt B' data in

"types" : [ "subpremise" ]

• subpremise indicates a first-order entity below a named location, usually a singular building within a collection of buildings with a common name.

[1135 Thomas Ln. Apt B, Hixson, TN 37343] as a json response..

"https://maps.googleapis.com/maps/api/geocode/json?address=[ADDRESS]&key=[KEY]"

returns:

{
   "results" : [
      {
         "address_components" : [
            {
               "long_name" : "b",
               "short_name" : "b",
               "types" : [ "subpremise" ]
            },
            {
               "long_name" : "1135",
               "short_name" : "1135",
               "types" : [ "street_number" ]
            },
            {
               "long_name" : "Thomas Lane",
               "short_name" : "Thomas Ln",
               "types" : [ "route" ]
            },
            {
               "long_name" : "Hixson",
               "short_name" : "Hixson",
               "types" : [ "neighborhood", "political" ]
            },
            {
               "long_name" : "Chattanooga",
               "short_name" : "Chattanooga",
               "types" : [ "locality", "political" ]
            },
            {
               "long_name" : "Hamilton County",
               "short_name" : "Hamilton County",
               "types" : [ "administrative_area_level_2", "political" ]
            },
            {
               "long_name" : "Tennessee",
               "short_name" : "TN",
               "types" : [ "administrative_area_level_1", "political" ]
            },
            {
               "long_name" : "United States",
               "short_name" : "US",
               "types" : [ "country", "political" ]
            },
            {
               "long_name" : "37343",
               "short_name" : "37343",
               "types" : [ "postal_code" ]
            },
            {
               "long_name" : "3744",
               "short_name" : "3744",
               "types" : [ "postal_code_suffix" ]
            }
         ],
         "formatted_address" : "1135 Thomas Ln, Hixson, TN 37343, USA",
         "geometry" : {
            "location" : {
               "lat" : 35.144887,
               "lng" : -85.24711000000001
            },
            "location_type" : "ROOFTOP",
            "viewport" : {
               "northeast" : {
                  "lat" : 35.1462359802915,
                  "lng" : -85.24576101970851
               },
               "southwest" : {
                  "lat" : 35.1435380197085,
                  "lng" : -85.24845898029152
               }
            }
         },
         "place_id" : "EiUxMTM1IFRob21hcyBMbiwgSGl4c29uLCBUTiAzNzM0MywgVVNB",
         "types" : [ "subpremise" ]
      }
   ],
   "status" : "OK"
}

Answer 3

The trouble you are experiencing goes back to the core philosophy and use case goals for the Google Geocoding API: identify the latitude/longitude coordinate of a structure or facility and plot it on a map. Secondary information (suite, apartment, etc.) is generally not necessary to fulfill that goal and is thus discarded or overlooked. Delivery points that have a structure per secondary number, e.g. an entire building for Suite 100 and another for Suite 200 are not particularly common and seem to fall outside of the intended users of the Google Geocoding API.

Furthermore, the API is an "address approximation" tool that guesses where an address might be. For example, if 121 Main Street has a building and 125 Main Street does too, but 123 Main Street isn't real, it will plot the address right between 121 and 125 as if it were there, even when the address doesn't exist.

If you're looking to verify the address (with or without secondary information) to make sure it's real and then plot it on a map, there are a number of services (both free and paid) that can offer this behavior. A simple Google search for something like "address verification" will give you a number of results for organizations that offer verification along with geocoding.

If the geocoding resolution from these services isn't good enough for your business needs, you will still want to have a cleaned address because it will then allow you to pipe those cleaned and verified addresses to another service--perhaps NavTeq--to get rooftop level data for locations that have entire buildings dedicated to secondary number (suite, apartment, etc.). Note that providers such as NavTeq are often incredibly expensive, so only you can make the judgement call if your business requirements truly demand the expense of ultra-precise resolution.

In the interest of full disclosure, I am the founder of SmartyStreets and we provide address verification and geocoding services. We're happy to help if you have additional questions.