Google's Geocoding API: Is There Any Good Alternative?
Google's Geocoding API is certainly one of the best known options, when it comes to using an API to geocode addresses. And, Google is usually synonymous with power and quality. So, does that reputation match up with the actual application of their API? If not, is there a Geocoding API better than Google?
The simplest answer to your questions is, 'It depends'.
Here is a list of the most common requirements people have when it comes to using a geocoding API:
- Limitations of Use
- Tech Support and Documentation
Based on these requirements, we evaluated five geocoding api providers: Google, TAMU, Loqate, Geocodio, and SmartyStreets. So, which of these is a good as Google? Here's how each of them rates:.
Geocoding API Requirements
"It's a one way street, but if the GPS says to turn left..."
The first and most obvious metric by which a geocode service can be judged is the accuracy of the geocodes themselves. Not all geocodes are the same, and some will take you right to an address's doorstep. It is important, however, to note that less exact geocodes aren't exactly useless. After all, "wrong" and "inaccurate" mean two entirely different things.
If you want to generate a geocode, there are really only two options. Either physically go to the address itself and write down what the GPS says when you get there, or use math to interpolate the position. The first is obviously the most accurate method—you can't get any more accurate than painting a big red "X" on the front door. We call this "rooftop level" accuracy, and this is the kind of accuracy Google provides.
Yes, that is good, if you must know.
The problem with rooftop-level is that it's hard to generate. It requires boots on the ground, and paying people to walk in those boots can be expensive. So what you gain in accuracy you usually pay for in price, so it's a trade off.
Conversely, the second method (called interpolation) gives you "block level" accuracy, and takes less effort. It involves taking two known points, then dividing the space between them to get estimated locations. Not quite skydiving onto the rooftop of the address you want, but it's more than enough to get an "I can see it from here" response. And because interpolation is based on doing the math rather than walking a beat, it often runs far cheaper than rooftop-level geocodes do.
So this trade-off is your first benchmark for geocode providers. Some of you are going to need something accurate enough to guide you to your destination walking backwards, blindfolded, on a moonless night. But very few of you will. For some, other criteria may be more important factors than the accuracy. In either case, the following description of accuracy found with popular providers should prove helpful.
- Google: "Rooftop Level" geocode accuracy
- Loqate: "Rooftop Level" on some, "Interpolated" on others.
- Geocodio: "Rooftop Level" on some, "Interpolated" on others.
- SmartyStreets: ZIP9 (What does that mean?)
"Is the engine supposed to be smoking?"
"Uptime" is a metric used to measure how long and how consistently a system has been, well, "up" and running. It's a way to find out if you should be worried that service won't be available when you need it. Unlike accuracy, uptime is not usually the sort of thing that you look at and say, "Yeah, I don't think I need 100%." You want someone on the other end when you pick up the phone and dial 911. You can't always plan when you're going to need the service, so you need the service to be ready at all times.
Imagine it for a second: You call 911 because your cat is stuck in a tree. But no one answers. In fact, you get a "Your call cannot be completed at this time" message. This is a minor emergency, so you shrug, grab a ladder, and rescue the cat yourself.
But then you get to thinking: what if that happens during a real emergency?
One-time or occasional users may be able to get away with depending on a service that doesn't boast world-class uptimes. Recurring customers, however, will need some assurance of reliability. That assurance usually comes in the form of a Service Level Agreement (or SLA); among other things, it promises uptime that meets or exceeds a certain threshold. Some providers don't make these commitments, though, and others will only offer to show their SLA to signed-up, paying customers. In this latter case, there's really no way to tell what kind of reliability you're getting before you start using the service.
If you're a regular user of geocode APIs (and if you're reading this article you either are or will be), then you'll want a system that guarantees it won't go out on you, and then keeps that promise. In short, you want an API with good uptime (don't we all?).
- Google: 99.9% Uptime SLA
- TAMU: No information without signing up
- Loqate: No information without signing up
- Geocodio: No SLA
- SmartyStreets: 99.98% Uptime SLA
"Are we there yet?"
Let's be clear on something first. Computers are fast. Really fast. We built them specifically so they can do things like geocoding, because they can work faster than we can. Kind of like cars—it gets us where we want to go in a fraction of the time.
Once we cut away incidentals like connection speed and substandard hardware, we see what really slows down computers: us.
We put a wide range of limitations on our machines that keep them from running full throttle. Some of the limitations used in the geocoding business are listed below, and beneath them are some elaborations on why they can sometimes be a pain in the patoot:
- "Requests per" methods of throttling
- Presence/absence of batch processing
- Capacity, i.e. simultaneous processing
The first traffic jam on the list is "throttling," which largely comes in two flavors: requests per second, and requests per day. Some similar limitations, like monthly subscription usage, can be increased by waving some additional legal tender in the provider's face. Real throttling, though, doesn't work that way. If a provider throttles usage, they do it universally and irrevocably, and they usually do it to make life simpler for themselves.
It's like this—if you're having trouble fielding all the requests at once that are sent to your servers, you have two options. First, you can increase the server capacity (see below) in order to continue handling the flow. That takes money; sometimes more money than it's worth. Or, you can slow the speed of incoming traffic by throttling it. You do that either by putting incoming requests in a queue, or by sending the user an error message that indicates they are over the request limit.
By controlling the flow, the provider can keep their servers from being overloaded, which can help them maintain uptime (which, remember, is a good thing). This does, however, reduce the speed at which they can return the geocodes back to you.
Next, let's talk about capacity. Most throttling occurs as a provider attempts to maintain uptime by controlling the flow of requests and keeping their servers from being overrun. Some providers, though, build their systems to handle large numbers of requests, and thus aren't afraid to let their customers turn on the fire hoses. Companies like this often don't throttle because they don't need to; regardless of the traffic, they can still pump geocodes out as quickly as addresses come in.
Whether you're baking 1,000, 10,000, or 100,000 cookies, having a large capacity helps both on the small scale and on the large scale—increased capacity means being able to process more requests simultaneously. This means that 100,000 addresses still process like 10,000 addresses. Turnover time is incredibly short, and any queueing that must happen moves quickly.
Lastly, the presence or absence of batch processing has an impact on the speed at which your geocodes come back to you. Some providers only offer one-at-a-time geocoding (the "enter your address here" line on the website). Even if the developer can set up a loop that plugs in address info as fast as the website can handle it, you're still likely to be throttled (see above), limiting how many requests you can push through per second.
Other providers do offer batch processing, allowing you to lump many requests together and submit them all at once.
Some providers have a command-line feature or some sort of copy/paste method on their website that's capable of receiving larger numbers of entries all at once. Using this method processes the addresses immediately, and the limitations to speed from there on are largely ones of capacity (see above). This is kind of like turning on a fire hose and aiming it their way.
The other form of batch processing (mind you, some companies offer both forms) is when you can submit something like an Excel file to the provider, neatly packaged. In this format, the provider can take however long they need or want to, and then notify you when the job is complete. That gives them the option to delay processing—sometimes even days—if it makes life easier for them.
Here's how Google stacks up against the competition:
|Name||Batch||Size of Batch||Requests per sec||Limit per Day||Time to process 10,000 addresses|
|Yes||No limit listed||5 (free users); 10 (paid)||2,500 (free); 100,000 (paid)||33 Min (free); 17 min (paid)|
|Geocodio||Yes||10,000 max||No limit||None||"A couple of minutes"|
|SmartyStreets||Yes||Any||No Limit||None||5 sec|
|TAMU||Yes||2,500 (free)||None listed||Must refresh credits every 2,500||Unknown|
|Loqate||Yes||No limit listed||None listed||None Listed||No estimate listed; signing up is the only way to learn more|
Additional note on Google: Most of Google's information is available on their site, but specifics on how a paid account works—prices, how to increase limits, etc.—are only available by contacting their sales department.
Limitations of Use
"Hey, what's this third pedal for?"
Google (as you'll see below) is kind of the Ferrari of geocoding APIs. It's slick, it handles well, and it can accomplish really impressive things at amazing speeds.
But—both with Ferraris and with geocoding providers—you need to ask yourself, "What am I not allowed to do?" Some providers restrict the usage of the data they give back to you, keeping you within boundaries they feel are helpful to their business. It's kind of like traffic laws, and as a potential customer, you should be aware of what kind of stop lights providers put on the use of their service. Here are some examples:
- Requiring data to be used only in conjunction with a specified program
- Requiring free geocoding services to be used only by non-profit organizations
- Requiring users to empty caches after a certain time period to prohibit storage of data
- Requiring users to reference or cite the origin of the data (i.e., the provider)
Depending on how you plan on using your data, you may be willing to live with these kinds of restrictions. Likewise, you might be willing to live with an API that's a bit clunky, or less than straightforward to operate.
Note: you'll also want to consider how easy an API is to integrate and use; what kinds of input or output are supported; how simple it is to interface with; how quickly it can be tied into your code, and so forth.
- Google: May cache geocodes temporarily but may not store long-term; geocodes only for use in connection with their Google Maps API, free service must be offered free to your customers
- TAMU: Must cite TAMU as source, and add link to their website
- Loqate: Sign up required to obtain additional information
- Geocodio: No listed restrictions
- SmartyStreets: No restrictions
Tech Support and Documentation
"I've got a buddy who's a mechanic."
Something that you might have overlooked, but is of critical importance is how easy an API is to deal with when something goes wrong. Good tech support helps resolve issues as they come up. Good documentation helps both to prevent issues and to assist users in resolving them DIY-style. Some providers are top-notch in this regard, while others have spent their efforts in other areas.
- Google: Extensive documentation (though it's not referenced or mentioned on the help page) which is difficult to locate and search; help page encourages searching Stack Overflow and Github and using Issue Tracker (for reporting bugs); email contact but no chat or Twitter, and phone line to actual tech support only available for paid customers
- TAMU: No documentation offered unless signed up; Phone contact, chat, and email contact, but no Twitter account
- Loqate: Documentation extensive, but lacks language library; no tech support phone line, but chat and email both supported
- Geocodio: Documentation extensive, includes multiple language libraries; email, chat, phone, and Twitter offered for tech support
- SmartyStreets: Extensive documentation, language libraries hosted on Github; phone, chat, email and Twitter all offered for tech support
"Could have sworn there was a restaurant here last time I came through."
"Address validation" is when a mailing address is compared against an authoritative mailing database (the USPS, for example). If the address matches one of the active mailing addresses on file, the address is validated—it's confirmed to be a real address. It helps make sure that data is accurate and verified, and that fictional or incorrect addresses aren't slipped into your database by mistake.
Why are we talking about this? Besides the riveting nature inherent in the subject of validation, we want you to be aware that not every geocoding provider validates the address you give them before they give you the geocode. That means, even if they provide you the geocode for a particular location, it doesn't mean that location is a real address. That might be important if you are sending something to that address, be it mail, a package or something else.
While lack of address validation should in no way be a deterrent, it is good to keep in mind that many of the providers that offer validation offer it for no additional charge. Below is the breakdown of all the providers we put on our list and whether they offer validation or not.
- Google: No validation
- TAMU: Yes, but validation API is a separate service and is in no way connected to the geocoding API service
- Loqate: Yes
- Geocodio: No
- SmartyStreets: yes
"I knew Disneyland was expensive, but this is ridiculous!"
Finally, we come to the one that makes the world go 'round. Price is often the deciding factor in choosing a provider, and there's a wide variety in the prices offered by these companies. After deciding which services you need, as well as the features you want, determining what you can afford to pay for is the critical ending to this process. It may even cause you to double back and reevaluate the items listed above to find out which ones you can do without.
However prices affect you, we hope that our research at least is helpful to you in making your decision more clear. Below are the providers with a $$$ rating indicating their price ranges. More $$$ mean higher prices, and a ? indicates a need to contact the sales department for further information.
- Loqate: $$$$
- Google: $$$/? (initial cost is for overages; you have to call in for a quote on contracts)
- Geocodio: $
- SmartyStreets: $$
- TAMU: $
The end of the trip
"Everybody wake up! We're here."
With all the myriad factors that affect your geocoding decisions, what's "good" for one customer might not be the right fit for another. Carefully consider each of your criteria, weigh your options, and choose the one that's best for your needs. If you'd like to try out SmartyStreets for yourself and see if it meets your needs, just set up a free account and test away!