[cgiapp] Re: [OT] Searching for a db of American Localities and Postcodes

[Ron Savage]

Hi Mark

On Fri, 2009-07-10 at 11:46 -0400, Mark Stosberg wrote:
> On Fri, 10 Jul 2009 11:07:20 +1000
> Ron Savage <ron at savage.net.au> wrote:
> 
> > Hi Folks
> > 
> > For a home-use module, I use American postal data from ZipCodeWorld
> > 
> > http://www.zipcodeworld.com/index.htm
> 
> I have dealt with this issue on a number of projects over the years.
> The most recent "open source" version of the data is US Census data from
> from a few years ago. However, New postal code databases are released
> *every month* with new updates. It's my sense you need fresh data about
> every 3 to 6 months to stay very current. 
> 
> It does seem like it should be public data, but it's not now. I have
> used at least 3 Zipcode vendors over the years. I quit using TPSnet,
> although I don't recall why now.
> 
> I'm currently using this vendor:
> http://www.zip-codes.com/
> 
> But they are not perfect, either. In a recent update, I had the
> geo-spatial data *disappear* in some zipcodes. The explanation was that
> it was determined that the coordinates needed to be recalculated, but
> weren't available yet. In that case, I would expect the vendor to do the
> service of continuing to ship the older slightly less accurate version
> rather than no coordinates at all.
> 
> Also note that there is sometimes a lag time between when new zipcodes
> are published and when the coordinates for the zipcodes are available.
> This vendor has been been shipping zeros for the coordinates in those
> cases.  Some other vendor (I'm not recalling which one now), "cheats" by
> using a post office location as the center of zipcode, until the
> official coordinates are published. I think that's actually the better
> behavior, because at least people in those zipcodes can search for
> themselves with *some result* rather than waiting months before the
> zipcode is useable in geo-spatial searches at all.
> 
> Because I have learned not to trust Zipcode vendors, we've written our
> own kind of zipcode update "diffing" tool, so with each update I can get
> my own report of which zipcodes have been added and removed, as well as
> which ones have missing geo-spatial data. Right now that tool is
> specific to our data model storage, so it's not suitable for release.
> 
> If you are also tracking zipcode updates for a project, I do recommend
> you QA the published updates like this... In my experience there are
> nearly always some anolomies that need reviewed and sometimes manually
> addressed.

Wow!

$many x $thanx for the details. I was not aware of those types of
complexities.

For my use not much is required, but I'll be more cautious now.

-- 
Ron Savage
ron at savage.net.au
http://savage.net.au/index.html