21–30 of 134 posts
...and use H3 instead! https://h3geo.org/
Very different use case -- ZIPs/ZCTAs have some semblance of population normalization
This makes joining disparate data sources quite easy. And this also lets you do all sorts of cool stuff like aggregations, smoothing, flow modeling, etc.
We do some geospatial stuff and I wrote a polars plugin to help with this a while back [1].
Earlier quoted context omitted.
Very different use case -- ZIPs/ZCTAs have some semblance of population normalization
Not necessarily true. The population isn't balanced at all between many. Census units are.
Instead of zip use the following? Use Addresses Use Census Units Use your own Spatial Index Why not lat, long?
It depends on if you want to model a point or an area. lat/lng gives you a point , but you often want an area to, for example, count how many people are in that area. A spatial index like H3 provides a grid of area units.
Anything else is a loose correlation at best, that will likely change over time.
Earlier quoted context omitted.
Very different use case -- ZIPs/ZCTAs have some semblance of population normalization
If you care about that and have a data source, you can add, for example, population density per H3 cell as part of your analysis. That has the additional benefit of denoting the this quantity of interest explicitly , rather than some implicitly assumed correlation which may not be true.
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…
At that point you need something like Smarty[1] to validate and parse addresses.
[0]: https://stackoverflow.com/questions/2783155/how-to-distingui...
CGP Grey recently posted a video on Zip codes, "The Hidden Pattern in Post Codes": * https://www.youtube.com/watch?v=1K5oDtVAYzk
To put it in plain mathematical language, ZIP codes are not defined as polygons [0]. The consequence is that performing any analysis with an assumption that ZIP codes are polygons is bound to be error-prone. 0: https://manifold.net/doc/mfd8/zip_codes_are_not_areas.htm
Yeah, but any analysis you're likely to perform is approximate enough that the fact that ZIP codes aren't polygons is basically a rounding error.
Plus, it's a lot easier to get ZIP codes, and they're more reliably correct, so you might still get better results, than you would going with another indicator that is either (a) less reliable or (b) less available.