354 karma · joined March 21, 2014
He loves programming, so much so that he dreams in C# and has nightmares about legacy code. He wears Transformers pajamas.
A few years ago, he staged a full-scale coup d'état and burned down the ivory tower where the software architects lived. Then, he sang and frolicked and danced about with the rest of the lowly software developers.
When he’s angry, he mumbles to himself and types more loudly on his keyboard. When he’s happy he mumbles to himself and types loudly on his keyboard as well.
You can read more about his blathering and rants on his blog: http://blog.jonathanoliver.com/
[ my public key: https://keybase.io/joliver; my proof: https://keybase.io/joliver/sigs/mg2KjhltwbuIV56Bt8iNzXVJjv1l_Q-N0K3F4o3efeY ]
We've been in the geocoding space for over 12+ years. A geocoding API should be easy to set up, deliver rooftop-accurate geocodes, be transparent about accuracy, persist in perpetuity, have a clear pricing structure, and be lightning fast.
Smarty has geocodes for 210 million US addresses, including 20 million non-USPS addresses. Our US Rooftop Geocoding product is 97% accurate to the rooftop or parcel of the property. Perpetual use of our geocoding data is also available, and Smarty does have licensing available for re-syndicating lat/long points in your APIs. Our entry-level plans for US Rooftop Geocoding have rate limits of 25,000 addresses/second. (Most customers won't reach this speed, but you're welcome to try.)
The best way to determine a company's geocoding accuracy is to test their products directly.
I know there are horror stories around this acquisition and lots of predictions about what will happen, but only time will tell. On a minimum, it has been a delight to use the Hashicorp software stack along with the approach they brought to our engineering workflow (remember Vagrant?). These innovations and approaches aren't going away.
I’d love to have you email your mailing address to support@smarty.com with a link to this HN thread. We may be able to help fix some of this.
We have non-postal addresses and a lot of other mechanisms to help here. We also have contacts at the USPS and others to help fix addresses.
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.
https://www.youtube.com/watch?v=TYsulVXpgYg
What could go wrong?
[1] https://en.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_th...
That guy really knows his stuff regarding performance.
It's been an incredibly smooth experience.
That said, the one thing that I still haven't migrated over to fully is Linux on a laptop. I'm macOS on an Apple MacBook Pro 14" (powered by Apple's M1 Pro).
> Watching non-programmers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf.
I'm pretty good at shell scripts but this guy is a master at his craft. Give him any problem and within a few minute he's got a series of piped statements through awk and a few other well-known tools.
Okay, now fast forward a few years: is the open source dependency still [original license flavor] or is the license now more restrictive? What about the the updated dependencies of this single, imported dependency?
Now suppose you have an executable that's made available: do you properly have the accompanying license files that (on a minimum) give attribution?
Generally speaking, we import dependencies to help make things better and to get back to get focusing on the main portion of our application. At the same time, each imported dependency has an ongoing management factor.
...and don't get me started on the diamond dependency problem which still exists despite any given package manager's best efforts and is one of the reasons we have SemVer which we hope is followed by the developers of that dependency.
Your mileage may vary.