Imagine honing in on familiar areas simply by typing the first few digits of a zip code—type “9” to immediately zoom into the US west coast, followed by “4” to zoom into the SF bay area and then “5” for the east bay. Because of the immediate feedback, the user can stop typing when she gets close enough, and use relative navigation from there.
This is really cool, but ultimately not that practical because it doesn't display the zipcode boundaries.
If it were integrated with zipcode boundary information as this [ http://www.usnaviguide.com/zip.htm ] site does with google maps, it would be pretty awesome.
Interesting idea. I didn't really try too hard making it a complete product, since I was only interested in proving the navigation concept that Bret Victor had described. But that's a good idea, and if you're interested feel free to fork it and add that capability!
I had the same concern when I built it, but the data source I was using only provides centroid information, not boundaries. I thought for a while trying to come up with a solution and ended up ignoring it, since I was mainly interested in a proof of concept. If you'd like to fork it and improve you're more than welcome to!
You should probably mention the caveats when using ZCTA's to get a list of zips... Namely that they don't include all zip codes, don't get updated as quickly, and may not actually represent the same thing as a zip code:
Interestingly enough zip codes don't cover the entire US. Not even the entire continental US. Lat/Long 40, -110 (in NE Utah) is a good test case to make sure your code handles that circumstance.
This might sound silly but you should actually have a "plus" plan or something that you charge for - free services have a problem of suddenly disappearing without any notice. Paid customers ensure that service will be available in the future too.
Very nice. Small enough that I can read and understand every line of code, and it still does something useful.
One thing I don't get, is why you're not using the zip code as the primary key (or have any other sort of index on it). The id isn't even used as far as I can tell. Is it just blazingly fast enough as it is?
The database is mostly an abstraction layer for other people to get up and running with the API. On ZipLocate.us everything is cached in memory using Varnish, so API calls never even hit the database. When data is updated, updated zip codes are just refreshed in the cache.
Like disdev, I always use an auto-incrementing id, but you're right that the index should be on the zip code instead of the id.
Personally, I always use either an auto-incremented ID or a GUID. I don't like using a real value of the object as a key. Generally, I think it's good practice, but you're right... I'd index off of that.
which uses browser location finding to tell you what postcode you are in (more or less). If you'd be interested, I have a beta API which will return full postcode info based on latitude/longitude; it's kind of beta, but I'd be happy to provide access if you need it.
CodePoint Open has been freely available for a number of years. It doesn't include delivery endpoints but for geolocating English, Scottish and Welsh (but, alas, not Northern Irish) postcodes it's fine.
Unfortunately we lost the postcode database as a public asset in 2013 when the UK government sold off Royal Mail[0], despite the database being compiled at huge cost to the tax payer.
This is a real shame as people had to campaign for years before the data was made freely available to begin with.[1]
Hopefully though, as long as the government still holds a large stake, we'll at least have Code Point. The Royal Mail also offer some developer options[2]
Actually, zip codes are proprietary business information of the USPS. Which is why ZipLocate uses ZCTA codes (similar, but based on data collected from censuses).
Looks nice, kudos for offering it for free - 5$/month is still not nothing. It would be grand if you included "US" somewhere besides the domain, because the service geolocates US zipcodes, not international zip codes.
Very often ZIP code is used as alias for postal code even in international context. I see "zip code" more often than "postal code" on international address forms.
Can you show me an example of an address form for non-US-based organization that exclusively uses the term "zip code"?
I'm not saying they don't exist, but I'm not sure I've ever seen one.
The US-based organizations using the term "zip code" for non-US addresses are doing so either out of ignorance or expediency, since fitting "zip/postal code" into a space is sometimes not possible.
I've seen it quite a bit in especially older e-commerce software, presumably developed for US use, then "internationalized" as a bit of an afterthought. I also think that many non-native-english-speakers assume zip code is the appropriate translation of postal code since it features rather prominently in (exported) US pop culture.
That doesn't make it correct, and I don't believe that some peoples unequivocally wrong usage of a term should oblige other people to qualify their correct and unambiguous usage of it.
Imagine honing in on familiar areas simply by typing the first few digits of a zip code—type “9” to immediately zoom into the US west coast, followed by “4” to zoom into the SF bay area and then “5” for the east bay. Because of the immediate feedback, the user can stop typing when she gets close enough, and use relative navigation from there.
I coded up an example a little while ago (http://andrewcou.ch/zip-to-it/).