[Geodata] [Tiger] A few interesting observationson theTiger2007fedata

[Stephen Woodbridge]

Bob Basques wrote:
> 
> Steve,
>  
> The census puts out a ZipCode Polygon Set, do you know where this 
> originates?

Yes, the Census creates this by looking at the edges of every block and 
assign the block the zipcode that is prevalent on the edges. It then 
merges the blocks based on the assigned zipcode and then does some 
additional (may be by hand) post processing to eliminate holes and 
islands and slivers in the polygons.

The purpose of these polygons it for tabulation reporting, hence the 
name of these polygons ZipCode Tabulation Areas (ZCTA).

There is a write up on the Census.gov site that I have come across that 
explains this process. While this give the allusion that Zipcodes are 
polygons they are NOT in fact. Zipcodes are carrier routes or paths the 
a postal carrier would travel to deliver mail for a given zipcode. These 
carrier paths are adjusted from time to time based on the needs of the 
USPS so they can be reasonably dynamic over time frames of years. And in 
reality because they are paths and not polygons they can cross over one 
another and intersect with other zipcodes along boundary areas based on 
the efficiency and needs of the USPS.

-Steve W

> Your last piece of the reply was what I was getting at.  The original 
> producer needs to be involved somehow in the bigger picture. 
>  
> bobb
> 
> 
>  >>> Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> Bob Basques wrote:
>  >
>  > 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.
> 
> The problem is that zipcodes are NOT polygons they are carrier routes.
> ZCTA's that the Census produces are non-overlaying polygons that roughly
> approximate the area encompassed by a carrier route, but it is possible
> for carrier routes to do weird things like criss-cross one another.
> 
>  > 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.
> 
> Right, but you have to convince the data producers of this, not us :)
> 
> -Steve W
> 
>  > 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
> 
> _______________________________________________
> Geodata mailing list
> Geodata at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geodata