Are the geocoding tools in Google, Bing, etc. good Enough? Part 1
Note: This is the first of a series of articles contrasting the approach of many geocoders, especially Google’s and Bing’s offerings, with enterprise/professional geocoding.
When Google introduced Google Maps in 2005(!), they elevated consumer-orientated mapping with ease-of-use, great coverage and innovative approaches. Microsoft followed, innovated and today, their current branding is under Bing and Azure Maps.
Besides pannable maps, they both included geocoding.
Geocoding systems from Google (in Google Maps) and Bing (in Bing Maps and Azure Maps) started small and have been expanded over these years – more countries, more capabilities, etc.
But at the core, these systems are consumer-oriented – designed to “give an answer.”
In many use cases, especially in business and government, the “good enough” approach of these systems is not good enough.
There are several aspects of these systems to look at.
First, let’s review basic geocoding.
What is geocoding? Simply, it’s the process of matching a location such as:
- an address (“Street-level geocoding”)
- postal (ZIP) code (“ZIP-Level or Postal-Level geocoding)
- city name (“City-Level Geocoding, not used as much anymore)
- county name, etc…
…to latitude and longitude coordinates on the Earth. The resulting coordinates are sometimes called a “geocode.”
In general, geocoding is a complex process. Geocoders work by using software algorithms to parse and infer information from the input and match to underlying map/address data. This is not an exact process. Some examples of the address processing required…
As you can see, it can be complicated.
Let’s look at one specific issue with some “not good enough” geocoders….
Geocoders have to parse addresses such 619 Main W Street, St Charles, Illinois 60174. It gets more complicated if the input address doesn’t include the “directional”, in this case “W” for West: 619 Main Street, St Charles, Illinois 60174.
In some cases, “not good enough” geocoders will pick the first match in a list, which could be East or West Main Street. A status code might be returned that it was a “good” hit because a street address was found.
This is why some of these geocoders are described as “giving an answer.” In all cases, the coordinates have four or more decimal places so even when looking at the results, it’s hard to tell that there is an issue.
FYI, both addresses are valid, although only the West address is deliverable by the USPS. The East address is now a parking lot. Depending on your application, the East address may be valid to find that location, no matter if it isn’t a deliverable address. For example, to find the closest ATM, entering the East address (even though it’s a parking lot) is perfectly valid, but it isn’t if your application has something to do with mailing, delivery, etc.
The point is you may need a geocoder with the capabilities to handle all of the issues that prevent finding the right geocoded coordinates.
Part 2 will cover something called “fallbacks” and result codes.
To probe further on our site:
Geocoding:
- As a REST Service
- As self-service cloud service (MapMarker Online)
- Enterprise requirements/Higher quantities. See the Enterprise Geocoding Module in Spectrum
Reverse Geocoding:
- As a REST Service
- Enterprise requirements/Higher quantities. See Spectrum
Address Validation/Correction:
- As a REST Service
- Enterprise requirements/Higher quantities. See the Universal Addressing Module in Spectrum
