[Geodata] [Tiger] A few interesting observations on theTiger2007fedata

[Bob Basques]

All,
 
I wonder if in the interests of making things simpler (Probably only for us Techies) if some of these attributes be left as a spatial lookup instead of binding as attributes.  I know that binding is a good performance improvement, but the original owners/publishers of the data seems to be more than just the census.  Does it make any sense to run things, where possible, as spatial lookups, where the points are spatially referenced inside of a ZIP polygon for example.
 
My suggestion has two big positives that I see, first there is much better control over who manages the poly layers and the number of possible iterations of something like this is endless, you could merge the request with just about any polygon once a system were set up.  Second, the job of keeping everything up to date in a timely fashion seems to be quite a task, any improments as far as automation would seem like a positive to me.
 
Another possible option, would be to build the spatial lookup mechanism, for the explicit task of building a attributed dataset.  This has the benefit of being able to (more) easily keep things updated over time.
 
Just some (more) thoughts.
 
bobb
 


>>> Stephen Frost <sfrost at snowman.net> wrote:
Stephen, et al,

* Stephen Woodbridge (woodbri at swoodbridge.com) wrote:
> It is also important to note here that the zipcode info in Census is by  
> and large circa 1990 when the Census last used the USPS Zip+4 database  
> and did a mass merge/update of Tiger. This has an impact in a couple of  
> ways:

Census has their seperate ZCTA system, but I don't believe that
means that the detailed per-segment Zip codes aren't ever updated..  It
would be easy enough to check (not that I have) obviously, by looking at
a recently added zip code and checking to find it in the latest Census
data anywhere.  I had thought that the Zip codes were updated as part of
the MAF improvment process at the detailed edge level though.

Just a thought.

Thanks,

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20080806/96ad07ea/attachment.html