<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2800.1505" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Comic Sans MS">
<DIV>Steve,</DIV>
<DIV> </DIV>
<DIV>The census puts out a ZipCode Polygon Set, do you know where this originates?</DIV>
<DIV> </DIV>
<DIV>Your last piece of the reply was what I was getting at. The original producer needs to be involved somehow in the bigger picture. </DIV>
<DIV> </DIV>
<DIV>bobb</DIV>
<DIV><BR><BR>>>> Stephen Woodbridge <woodbri@swoodbridge.com> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Bob Basques wrote:<BR>> <BR>> All,<BR>> <BR>> I wonder if in the interests of making things simpler (Probably only for <BR>> us Techies) if some of these attributes be left as a spatial lookup <BR>> instead of binding as attributes. I know that binding is a good <BR>> performance improvement, but the original owners/publishers of the data <BR>> seems to be more than just the census. Does it make any sense to run <BR>> things, where possible, as spatial lookups, where the points are <BR>> spatially referenced inside of a ZIP polygon for example.<BR><BR>The problem is that zipcodes are NOT polygons they are carrier routes. <BR>ZCTA's that the Census produces are non-overlaying polygons that roughly <BR>approximate the area encompassed by a carrier route, but it is possible <BR>for carrier routes to do weird things like criss-cross one another.<BR><BR>> My suggestion has two big positives that I see, first there is much <BR>> better control over who manages the poly layers and the number of <BR>> possible iterations of something like this is endless, you could merge <BR>> the request with just about any polygon once a system were set up. <BR>> Second, the job of keeping everything up to date in a timely fashion <BR>> seems to be quite a task, any improments as far as automation would seem <BR>> like a positive to me.<BR>> <BR>> Another possible option, would be to build the spatial lookup mechanism, <BR>> for the explicit task of building a attributed dataset. This has the <BR>> benefit of being able to (more) easily keep things updated over time.<BR>> <BR>> Just some (more) thoughts.<BR><BR>Right, but you have to convince the data producers of this, not us :)<BR><BR>-Steve W<BR><BR>> bobb<BR>> <BR>> <BR>> <BR>> >>> Stephen Frost <sfrost@snowman.net> wrote:<BR>> Stephen, et al,<BR>> <BR>> * Stephen Woodbridge (woodbri@swoodbridge.com) wrote:<BR>> > It is also important to note here that the zipcode info in Census is by <BR>> > and large circa 1990 when the Census last used the USPS Zip+4 database <BR>> > and did a mass merge/update of Tiger. This has an impact in a couple of <BR>> > ways:<BR>> <BR>> Census has their seperate ZCTA system, but I don't believe that<BR>> means that the detailed per-segment Zip codes aren't ever updated.. It<BR>> would be easy enough to check (not that I have) obviously, by looking at<BR>> a recently added zip code and checking to find it in the latest Census<BR>> data anywhere. I had thought that the Zip codes were updated as part of<BR>> the MAF improvment process at the detailed edge level though.<BR>> <BR>> Just a thought.<BR>> <BR>> Thanks,<BR>> <BR>> Stephen<BR><BR>_______________________________________________<BR>Geodata mailing list<BR>Geodata@lists.osgeo.org<BR><A href="http://lists.osgeo.org/mailman/listinfo/geodata">http://lists.osgeo.org/mailman/listinfo/geodata</A><BR></DIV></BODY></HTML>