In a previous post, I described how to use the MapQuest API and retrieve a user's current address via a reverse lookup. Almost immediately afterwards, MapQuest changed the terms of their API and now they are looking to implement a token based authorization system to prevent abuse. I thought:
Why not implement my own reverse lookup? How hard could it be?
The actual problem I am trying to resolve by doing a reverse lookup is the following:
Using a latitude and longitude, a point, provided by a user, I want to determine what zip code and county that user is in.
Currently, the only data I have is centroid data for every zip code in the US. Naturally, I thought I could do a distance calculation from one point to another.
This approach is flawed.
In the image, we have two zones. Zone 1 is adjacent to Zone 2. Zone 1 is larger than Zone 2. Zone 1 has a centroid further from the edge than Zone 2's centroid is from its edge. The user is located in Zone 1, but is closer to Zone 2's centroid. This is not the result we want.
The Solution (I Think)
The solution is pretty easy to see from the image. Instead of calculating distance, what we actually want is intersection.
What county and zip code does the point intersect with?
To solve this problem, we need polygonal data for all counties and zip codes in the U.S. That is a lot of data, coming in at almost 40 gigabytes and growing for the entire planet.
A Better Solution
Instead of building this myself, I believe I should trust a third party that specializes in this field. I like what Mapzen is doing and looking forward to using their Pelias API. They have generous API limits and seem to be doing some awesome stuff.