Ziptastic: Isn't a zipcode enough? | Hacker News Reader

Ziptastic: Isn't a zipcode enough?

daspecster.github.com

138 pointsdaspecster110 comments

I'm not sure if this is supposed to be USA-only or not. It seems to ask for 'country', so I assume it's aimed at the whole world.

And here's where reality disagrees with your simple organisation.

* First "zip code" is mostly an American term, "post code" is used in other anglosphere countries.

* Not all countries have "everyone is in a city" model, this seems to happen in the USA, where 'city' is often an administrative division, and you can have a city of 1,000 people. "County" would be used in Ireland & UK.

* In some places Country = State, e.g. Ireland. The law & Consitution there consistantly refers to 'Irish State'. Likewise the European Union has 27 member states. Each State is a Country. (Some States (e.g. UK) are made up of several countries).

* Some places don't have post codes (or zip codes) at all. (e.g. Ireland).

Addresses are hard.

Yeah this doesn't work at all if you live outside USA. The post code for Auckland CBD (in New Zealand) is 1010.

So if I try http://zip.elevenbasetwo.com/?zip=1010

It gives: {"country": "US", "state": "MA", "city": "BRIMFIELD"}

I'm guessing it's a leading zero problem, since all US Zipcodes are 5 digits (or nine). Going to http://zip.elevenbasetwo.com/?zip=01010 gives the same response noted above.

Same for Australian zip codes e.g. 2000 (Sydney) returns a 404 (doesn't exist)

Despite the mentioned problems with this method I still think it is a great start and should be implemented more often. The U.S. GDP is three times larger than any other economy, there is no doubt that for a lot of sites, US addresses are the norm. Even if it is not 100% accurate it would still be nice to pre-populate fields and let the city be changed if it is incorrect.

The U.S. GDP is three times larger than any other economy

Eh? The GDP of the European Union is larger than the USA.

(A lot of this now hinges on how you defined 'country' or 'economy'. I'll point out that most law comes from european level and EU passports say "European Union" on the front :P )

On the third bullet point, that's just a word with two meanings, not a country-to-country difference. The USA is also a State in that sense: it has a Department of State to handle state-to-state affairs (i.e. foreign affairs), is a Member State of the United Nations, etc. The use of the term "state" for a subnational division, roughly akin to a Canadian "province", is a different meaning with the same spelling.

The same is true in some European countries; for example, Austria is a member state of the EU, but its subnational entities (Länder in German) are conventionally called states in English also.

And you can also call all of Austria a `Land' in German. Same applies to Germany.

The use of the term "state" for a subnational division, roughly akin to a Canadian "province", is a different meaning with the same spelling.

Fun fact, Ireland has provinces (4 of them). However they aren't used for addresses, only for sports or cultural reasons. So Dublin (the city) is in the State of Ireland, and the Province of Lenister. Sometimes the web forms will have a field saying "State/Province", and I wonder which to put in.

The Government in Ireland is currently in the process of introducing postcodes http://www.dcenr.gov.ie/Communications/Postal/Postcodes.htm

They've been talking about that for years. It won't happen. We don't have the money, and the gov doesn't want to waste money on mostly pointless systems, i.e. a repeat of when they tried to bring in evoting

In France, Paris, Lyon and Marseille have multiple postal codes, and some postal codes are used for multiple cities (postal codes were attributed to delivery offices in 1972, and new offices now use the number of the nearest numbered office).

(And no, Ziptastic doesn't work for French postal codes.)

It doesn't even work (perfectly) within the USA. Zip codes are so unreliable that they're not even used by other government agencies/projects - take a look at the Census, which uses ZCTAs: http://en.wikipedia.org/wiki/ZIP_Code_Tabulation_Area

The reason for this is that the USPS can change the zip codes without warning (and furthermore, leaves some areas undefined), whereas the Census needs reliable boundaries and fixed geographic areas.

Getting things delivered to the Republic of Ireland is a major pain because of this. I've had deliveries delayed because the company in question doesn't believe my address is real or correct. It doesn't contain numbers, the word 'street' or a postcode. Some sites also flag your order if you put 0000 in as a postcode for example. Some enterprising guys have created an unofficial "Location Code"[1] for Ireland to help solve some of these problems but it all comes back to faulty assumptions.

[1] http://www.myloc8ion.com/

ZIP Code is a trademark of the US postal service; so yea, US only.

Brazilian post codes map to [segments of] streets, with the format XXXXX-XXX. The API response for a brazilian post code is just "404", invalid if the application was expecting JSON.

Doesn't work for German zip codes. Returns 404 or some US city with the same code.

Unfortunately in some cases a zipcode is in fact not enough, as it's possible for a zipcode to spread across multiple towns. However, if you have a full 9 digit zipcode then you can in fact always determine. However, even if you can't always determine this information exactly, a zipcode should be enough to pre-populate these fields for you most of the time, and in those rare cases which they don't a choice can be presented of only those qualifying choices.

The USPS has a pretty decent API that should allow this relatively easily.

Thanks! I will be looking into this more. I'm aware of the 9digit zipcodes. I'll look into the USPS API. Also, I'll address the other comment below. That might answer some questions.

My only problem with 9 digit zip codes is that I have no idea what mine is. I know the first 5 but not the last 4. If you have multiple addresses or move around a lot its not something you are quick to remember, at least for me. I wonder how many people actually know their 9 digit zip.

This is fairly useful if you are trying to get mailing addresses, though you have to be careful about rural route areas and other crap. There are also plenty areas where people are required to use mailing addresses that do not match what the zipcode says.

This is completely non-useful if you are trying to get residence addresses. Among other things: 1. There are plenty of places in the US where the zipcode serves an area many miles (IE 20+) away from the "city" associated with the zip code.

2. Postal boundaries do not match a lot of boundaries, and aren't updated as often. There are times when, for example, zip codes for towns in maryland were served from DC. So if you did reverse lookup on zip code, it would give you the wrong state and city.

This still happens near boundaries of states.

3. ZIP+4 does not solve these issues with enough accuracy (It's only about 95% accurate). ZIP+9 is still wrong about the city in plenty of cases.

Also, zip codes may change service areas each year, and so would be necessary to use 3rd party zipcode database and do a spatial join to add city, county, state attributes to each zip code. then import this table to mysql as lookup table.

For example: 94062 can be either Woodside or Redwood City or Emerald Hills.

Yup, here the USPS response to 94062

https://tools.usps.com/go/ZipLookupResultsAction!input.actio...

Note that it says "the actual city in 94062 is REDWOOD CITY." The others are merely "acceptable." For mailing purposes, at least, I understand this to mean that the USPS would prefer you to address mail items to Redwood City, regardless of what administrative entity the recipient is in (e.g. Woodside).

Of course, if you're using the information from this API for purposes other than mailing, such as providing an address for verification along with credit card processing, I suppose your processor won't like seeing Redwood City if the cardholder has Woodside on file.

I plugged in 45440, and it returns Dayton as the actual city, but Dayton is miles away.

It returns a bunch of other cities as acceptable, but those are the ones that are actually located in that zip code. I'm curious as to what all of this returned data actually means.

You could always have the city state and country pop up as separate, pre-filled input boxes once the zip code is entered, so the user has a chance to correct it.

Or even just pop up all the possible options. Still an immense and very much appreciated speedup.

I worked for Avalara.com for a while: they help companies calculate sales tax based on location. I learned there that the five-digit ZIP code is certainly not enough. Some five-digit ZIP codes cross state boundaries, for one thing.

My big pet peeve is when they ask you what type of credit card you're using, when that is easily determined by the first four digits of the CC number. Thankfully, more and more web sites are figuring this out.

Even less than that -- if the card # starts with "4", it's Visa; 36|37 is Amex; 5[1-5] is MC and so forth.

Totally with you, why do I have to choose from a dropdown -- you already have my number!

6 is Discover

I've never understood why that information is required at all in the first place. I can see the usefulness of showing which credit cards the site accepts but to force the visitor to choose one seems wasteful.

I think it's a round-about way of saying "We don't take (American Express|Discover|Diner's Card|whatever)" without actually saying it.

Modern processors accept just about everything nowadays, but this was less common even a few years ago.

I think there is a very good reason to do that — sites that don't accept all credit cards. I don't want to sit there typing in my American Express card number only to find out that it is not supported afterward. Now the sites that have a nice little pop-up showing me the detected card type are really nice and give me a nice warm and fuzzy feeling after giving them my card number.

I use this database in my apps to solve exactly this problem (US only): http://federalgovernmentzipcodes.us/

No idea who runs it but its updated regularly and has never caused issue (so far). It includes both the USPS preferred city and all possible cities so you can either default to preferred or provide at least auto complete. Its also has all the military addresses and as well as lat/long, which is a bonus.

I can see the ziptastic concept being interesting if it was fully international but for just the US it takes about 15 minutes to download the linked csv, toss it in a DB table, and write the 3 queries you need. I don't understand the need for a service to handle such a simple task.

Yes, it seems like the dataset is so small that one should just download the whole thing and periodically request diffs. Less total bandwidth for everyone, more reliable, and a nice user latency win as well.

I just love it when people create projects to solve problems that have already been solved before. 5 minutes of web searching would have told you:

* The USPS already has this information

* ZIP codes are not precise enough to provide a single city/town result (in fact, many web sites already get this wrong).

* ZIP+4 codes will give you block-level detail, but I doubt more than a few percent of people know what their +4 digits are.

The USPS already has this information

The USPS does have this information, but when I checked a year or two ago, you either have to (1) agree to use the information only for purposes of mailing packages, per their TOS; or (2) pay them, e.g. something like $500 for a list of all five digit ZIP codes plus associated cities and states (the "City State File").

Corrections very welcome!

Edit to add: As philfreo asked, I'm also very interested in knowing where the data in zipcodes.db comes from.

What a poor attitude.

* Who cares if the USPS already has it? The app developer is the one seeking it.

* And USPS does not give the DB away for free.

* Your attitude sucks. And your 5 minutes of searching were not enough.

Less space than a Nomad. No wireless. Lame.

Just as a note, I know that for e-commerce shopping cart forms, we specifically force users to enter their address information and zip code.

No matter what you think, users aren't paying attention to what they enter in the forms. Forcing them to enter their address and zipcode allows you to do a cross check to make sure they entered everything correctly.

You may find it annoying, but when it prevents people from ordering items to the wrong address, it's a pretty useful extra field.

Totally agree! The jQuery plugin that I started working on will actually just populate those fields in the form so they can be changed after the fact.

Feel free to contribute! https://github.com/daspecster/ziptastic-jquery-plugin

If you are using jQuery, then why `var client = new XMLHttpRequest();` for the love of god, embrace `$.ajax()`

I love APIs. One recommendation though would be to change the server response slightly for the API call. In Chrome, it had me download a file instead of showing the response in the browser. I think it might be because the response has a Content-Type "text/json" instead of "application/json".

http://stackoverflow.com/questions/477816/the-right-json-con...

Thanks! Change made. https://github.com/daspecster/ziptastic/commit/de2cf83274b81...

I know it's been xerox-ed beyond original usage, but ZIP is an acronym - http://en.wikipedia.org/wiki/ZIP_code - "Zone Improvement Plan". Bugs the heck out of me that people don't treat it as an acronym.

I have spoken.

That is all.

If we're going to be unnecessarily pedantic, the canonical phrase is: "Ah has spoken!" ( http://en.wikipedia.org/wiki/Lil_Abner )

When you query for an inexistent postal code (i.e. http://zip.elevenbasetwo.com/?zip=101)

the page returns "404" as content but the response header is "200 OK".

That is inconvenient, and RESTfully wrong.

UPDATE: added pull request https://github.com/gbaygon/ziptastic/commit/7284cb2e4f863161...

It has nothing to do with REST.

REST != HTTP

The point is that regardless of naming, it's not standard HTTP, nor convenient for the developer consuming the api to return soft 404's.

Consider 33042, "Summerland Key." This ZIP code covers several other Lower Florida Keys, including Cudjoe Key and Upper Sugarloaf Key. "Summerland Key" is technically correct, since the post office is on that island, but people on the other islands will _never_ write "Summerland Key" as their address, preferring instead to use the ("acceptable") name of their island instead. I'm sure this situation is not unique to the Florida Keys, and I therefore doubt the usefulness of resolving city and state from ZIP code outside of them there fancy big cities.

I went ahead and setup http://ZiptasticAPI.com/ instead of using GET you just add the Zip code to the url ex: http://ZiptasticAPI.com/40504 all the code is on github https://github.com/joshstrange/Ziptastic I just wanted something a little cleaner and without using GET.

Feel free to fork it on github!

The problem with this service and smaller services like it is that they are very likely to go offline with no warning.

Well, one nice thing is that you can fork it on github and setup your own API server. My main goal is to change how forms on the internet are filled out and to reduce the barrier of entry for people trying to give company/people money or information.

Ah, good point, I suppose an organization could just run this internally.

while that's true, at least in this case the fallback would just be that the user has to enter in their city and state.

If you're going to do this, do the whole enchilada: zip code + person's name ought to give you their whole address for 99% of the population (hint: voter records). Well, 95%, considering such records are often out of date.

The problem is this will likely spook many people - "how does this website know my street address?"

Besides spooking people out, they may not be using their residential address in the case of a shipping address and at times billing addresses. We regularly have a customers shipping address be their office and (surprisingly) it's not uncommon to see P.O. Boxes for billing addresses.

>The problem is this will likely spook many people - "how does this website know my street address?"

I requested a car insurance quote from Progressive, and the first form in the process asked for my name and street address. After that, it gave me a list of the vehicles I owned and asked which one was I inquiring about.

I know that these are public records, but it still seemed a little creepy to me.

More sites need make good use of every publicly available record, as well as everything that can be inferred from them.

Maybe if more people get creeped out, they'd understand how scary the modern age is and we'd get finally get some decent privacy laws.

Are you aware of a voter registration database that's reasonably complete and up to date, and doesn't cost a ton of money to access? I'd love one for a current project, but my initial research seemed to indicate the only solutions were priced out of our budget (either in straight dollars, or in the man-hours to cobble together multiple sources).

Well, I don't know what a "ton of money" is, but there are a number of companies that have collected voter information US-wide and make it available:

http://www.politicalforce.com/ods_tutorial

Of course the same data (better!) is available from the big consumer database vendors as well.

Or do the whole enchilada with beans on the side.

Present a blank form with the usual fields: Name, Address, Birthdate, and so on. The user fills in whatever information they want, and the software uses multiple data sources to infer the missing information and fill in the missing boxes as the user types. Each character or field might be colour coded according the conditional probability of its being correct, or a drop down menu may appear once the number of alternatives is manageable.

Bonus points if the software can solve the inverse problem: Given an identity and partial information, what is the minimal required set of publicly available information required to establish a unique identity.

Edit: fix grammar

(hint: voter records)

Aren't most of the electoral register lists only legally allowed to be used for certain purposes? You might run into legal trouble if you were to use them like this.

Their donate page isn't using SSL.

I was just about to say the same thing. I also noticed it doesn't ask you for the name on card. I'd suggest using PayPal or Google Checkout with the whole trust issue.

Really bad. Use PayPal for donations.

No don't, unless you're a real charitable organization. Would be better to offer a premium tier.

Don't ever label anything as a donation via PayPal unless you have the actual documentation to back this up. Depending on your situation, your account can be locked when failing to provide the information, and worse, to be able to unlock it you have to refund the monies received and then ask for it again via a different method - if you can get it unlocked.

To avoid the PayPal/Donation problem, why not sell something, e.g. API docs. You pay €X and the author will send you a HTML file of the API docs. One-time, once-only price.

Then you have something you sold and you can use the money for hosting, avoiding 'donation' entirely.

If you view-source, you will notice that they are using stripe.com. This is actually a clever trick in that the form is intercepted by javascript, securely transmitted to stripe for processing, then a token is returned to the calling web site with success codes, etc needed for future billing questions, refunds, etc. The issue is that we have (rightfully so) trained people to look for the lock icon, look for https, look for the green location bar, ... Stripe goes a long way in protecting the transaction and reduce the merchant's PCI-DSS scope (really important for small merchants and large alike...), but merchants must still convince their customers that the site the customer is interacting with is safe to deal with.

It's more secure than transmitting the data in the clear, but still not really secure. A MITM could trivially rewrite the form to steal your data when submitted, and the user wouldn't be able to tell unless they inspected the source.

I'm actually impressed it came back with my correct information. On major websites including Target.com, they do not see my zip code as valid even though it's close to a decade old. Sure, it's knew in the grand scheme of things but that's crazy...

Anyway, I agree with the others that while this is nifty it won't always be accurate for everyone. For instance my township is contained within a very, very large county so typically mail is addressed to the specific township rather than the county. I do not know how or if that could even make a difference but our local post office has suggested it.

Overall pretty interesting idea. I think using this plus a way for users to validate the information found it could be useful. The only thing I would be wary of is the website is technically sending a third party the user's information. Your service could then build up information regarding a website's typical customer. Probably not something to worry about but I know most of the places I've worked at they WOULD NOT allow this; they downloaded their own offline zipcode lookups.

EDIT: Perhaps a way to download and get offline updates would be helpful especially if your website went down.

My understanding is the whole point of a zipcode is that city and state on a mailer don't matter at all. Doesn't zipcode go to a specific post office?

That is my understanding as well. The person at our local post office recommended putting the township but wasn't aware of exactly why.

My suspicion is that it doesn't matter one bit but I don't know anything about the USPS system.

I believe to a point it matters. In high density areas there might be a few distribution centers for mail. So the 9 digit zipcode is important. Also, the address lines are still very important. i.e. 1234 mystreet st. apt #2

Depends on if you mean ZIP or ZIP + 4 or ZIP + 4 + delivery point.

ZIP alone will route to a post office, but here are a significant number of areas where city is needed to further disambiguate due to duplicate street addresses in a delivery zone. Now, they obviously try to avoid this, but it still happens.

ZIP+4 would obviate the need for city, state.

ZIP + 4 + delivery point would obviate the need for everything :)

(The need for delivery point is because even a single address may have multiple mailboxes, etc)

Do you have an example of where city would clarify a zip code further? I'd expect large cities to be the case, but New York, NY seems to get everywhere, so maybe it's country roads? And state is certainly unnecessary, are there any zipcodes that cross states?

The whole world has postal codes. Some are simpler than others. It would be nice to see an API like this one that supported more than just one country.

Not everyone does.

"In February 2005, 117 of the 190 member countries of the Universal Postal Union had postal code systems. Countries that do not have national systems include Ireland and Panama."

http://en.wikipedia.org/wiki/Postal_code

The whole world has postal codes

Nope. e.g. Ireland

Where's the data from?

Full ZIP codes are actually 9 digits: a 5 digit prefix, which is what people are used to -- and a 4 digit "block" extension.

Each city will typically have many block extensions, and probably multiple prefixes associated to it.

Full ZIP codes are actually 11 digits: a 5 digit prefix, a 4 digit delivery-route-location code, and a 2 digit delivery point number. This 11 digit number uniquely identifies every single place the USPS can deliver mail.

Plus it's not cheap to implement a proper address coding system that conforms to USPS let alone the rest of the world. The USPS data alone is around $4k per year to license (it gets updated every couple months.

Very useful. Saves the user 2 to 3 steps. In rare instances where it returns the wrong city, they can modify the returned values. Probably want to skip ziptastic for non U.S. IP addresses.

Except then the zip would need to come before the city/state visually, which sounds awkward for most uses.

I fucking love this. I know that it doesn't work for a lot of people outside of the US, but with some modification it can definitely work for certain countries and communities. Fork and individualize to your needs.

My partner and I are currently working on a startup where location is everything, and we're very much on top of trying to make it as fucking simple as possible to do the basic tasks. Don't annoy the people that might give you money, as it were.

This will be a very useful tool in our belt.

Also zip (postal code) information is not in the public domain in the UK. It is a commercial database which you can licence from the RoyalMail or probably a reseller.

Yes. You can get a coordinate - postcode list though: http://www.ordnancesurvey.co.uk/oswebsite/products/code-poin...

Is the fact that so few sites actually implement this behavior evidence that it's not as beneficial as it seems?

Would be nice to see a complete, "best-practice" implementation.

Would love to see a cross-country solution here. Data should be available for free in every contry that actually use postal codes.

I agree, it's in the plans and on my trello board.

I'd prefer the opposite. I don't find the OP's "problem" that annoying, but I frequently send stuff to family and friends whose addresses I remember but whose ZIPs I can never keep straight, and it would be great if forms auto-filled that part.

Do most webapps and startups ask for a zipcode as part of the signup process?

ugh. how about you put some HTTPS on your credit card donation page?

doesn't google do this too?

http://maps.googleapis.com/maps/api/geocode/json?address=488...

As a super-fancy bonus, that also works for non-U.S. codes. Though yes, TOS will definitely be a concern for commercial use.

There's a neat interactive version of the same thing here (Java required): http://benfry.com/zipdecode/

Hong Kong has no zip or postal code. It's frustrating whenever a system requires these fields (which a lot do, though "HK" generally works).

Wouldn't a one to many look-up table suffice? X County, Y State = N1, N2, N3... zipcodes

I got 404 for my German code.

I think you should also add the zip boundary

I tried this many years ago, and it decreased conversion.

I'm not sure if this is still true, but apparently the surprise of a slightly unconventional form threw some people off, as it increased cart abandonment compared to a typical form.

If you're going to use this, please check to see if it actually provides a benefit to your users.

I love Twitter bootstrap but can people take a few minutes to customize the colors just a bit? Is that too much to ask for?

Does it really matter in this sort of case? It's a single parameter, single use JSON API. The documentation is essentially a single line of text.

If it was a GitHub `README.txt` file you wouldn't be complaining that it looks like every other GitHub readme.

Reply on news.ycombinator.com