41–50 of 134 posts
The alternatives that the author suggests are much more complicated, both in terms of the implementation and in terms of convincing the user to give you their full address.
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…
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…
The functionality of it is closer to the "Zip+4" with extension used to have a more granular routing of physical mail for USPS.
https://www.canadapost-postescanada.ca/cpc/en/support/articl...
http://federalgovernmentzipcodes.us/free-zipcode-database-Pr...
Which is derived from longitude and latitude..
H3 is awesome here! What I don't think many people realize is that H3 cells and normal geographic data (like zips) are not mutually exclusive. You can take zip outlines, and find all the h3 cells within them and allocate your metric accordingly (population, income, etc). This makes joining disparate data sources quite easy. And this also lets you do all sorts of cool stuff like aggregations, smoothing, flow modeling,…