zlacker

>>voxada+(OP)
ZIP codes are an emergent property of the mail delivery system. While the author might consider this a bad thing, this makes them "good enough" on multiple axes in practice. They tend to be:

- Well-known (everybody knows their zip code)

- Easily extracted (they're part of every address, no geocoding required)

- Uniform-enough (not perfect, but in most cases close)

- Granular-enough

- Contiguous-enough by travel time

Notably, the alternatives the author proposes all fail on one or more of these:

- Census units: almost nobody knows what census tract they live in, and it can be non-trivial to map from address to tract

- Spatial cells: uneven distribution of population, and arbitrary division of space (boundaries pass right through buildings), and definitely nobody knows what S2 or H3 cell they live in.

- Address: this option doesn't even make sense. Yes, you can geocode addresses, but you still need to aggregate by something.

>>jonas2+Xd
This is a tangent, but addresses are also way more complicated than most people realize - especially if you’re relying on a user to input a correct address or if you need to support multiple countries, somewhere with unique addresses like Queens[0], or you need to differentiate between units of a specific street address that uses something other than unit numbers for a unit designation.

At that point you need something like Smarty[1] to validate and parse addresses.

[0]: https://stackoverflow.com/questions/2783155/how-to-distingui...

[1]: https://www.smarty.com/

>>ericra+Um
Thanks for the shout-out. Founder of Smarty here.

Regarding article, it really depends on the use case of whether to use ZIP Code (TM), postal code, Canada Post Forward Sortation Area, lat/lon, Census Bureau block and tract, etc.

As has been noted, the ZIP Code is often good enough for aggregating data together and can be a good first step if you don’t know where to start.