In this guide, we’ll run down the differences/ similarities between Google & LocationIQ APIs. While switching from Google to LocationIQ is straightforward – as the two APIs are fairly similar – there can be certain differences that don’t appear obvious until you’ve spent some time with both the solutions. The objective here is to showcase the simplest, least painful way to make the transition.
—————————-
This is part 1 of a 5-part series.
- From Google to LocationIQ: Geocoding
- From Google to LocationIQ: Static Maps
- From Google to LocationIQ: Maps
- From Google to LocationIQ: Directions (coming soon)
- From Google to LocationIQ: Snap to Roads (coming soon)
—————————-
Your standard REST geocoding API call contains 5 basic parts:
- Endpoint
- Unique token/ API KEY
- Query
- Input parameters
- Output labels
1. Endpoint:
Switching the endpoint for geocoding is fairly straightforward:
Unique token/ API KEY: Google & LocationIQ both require you to input the key as a ‘&key=’ parameter.
2. Query:
There is a slight difference in the input parameter for address. Google requires you to input it as ‘&address=’ and LocationIQ uses the ‘&q=’ parameter
3. Structured Query:
For those instances where you want to search for a particular label and don’t want to restrict yourself to a freeform query. (These parameters cannot be used in conjunction with a ‘q=’ parameter)
Note: This is experimental. Please refer to point 2 above if this does not give good results
4. Additional Parameters:
This is where a bunch of things diverge. We’ve listed down parameters used to display & refine the response.
5. Output labels:
Addresses are weird. Every country has a different way of presenting addresses and every geolocation solution has a different way of interpreting that information. For example, a particular rural area might be labelled as town in Google API and labelled as a ‘hamlet’ in LocationIQ. It does not mean the area is definitely a town or a hamlet, it is merely interpreted as such.
Fortunately, LocationIQ has a way to normalize such oddities (with the ‘&normalizecity’ parameter). A quick summary below:
* If the type of the place is a recognized point of interest, “address29” will be replaced by the “type”. Ex “Empire state building” would be “attraction: Empire state building”. If the type is not recognized, it will be listed as “address29”.
* Above values are returned depending on the availability and results
Did we miss something? Write to us with details on your deployment – we’re happy to help!