I agree with Gary and wanted to just point up another potential source of
trouble: U.S. industrial parks can have zip codes, even post offices, with
location attributes aliased to another post office that could be miles
away. So they geocode like a P.O. box at another branch. I bet there's a
good name for this phenomenon; I call it by any one of several four letter,
unrepeatable words.
Sam Kome
Gary wrote:
> Derek,
>
> I don't know if this applies to the specific problems that you
> encountered, but I do know of a few caveats to be aware of when dealing
> with US zipcode files (this may or may not apply to other nations'
> postal codes):
>
> First, you need to understand that attempting to place a geographical
> limit on a zipcode is, at best, an estimate. Zipcodes are not defined
> by the USPS in geographical terms. They are a compilation of carrier
> routes, which, in turn, are each a list of addresses. Vendors that
> attempt to place boundaries around this are making a guess as to what
> the area covered by those addresses are. By attempting to create these
> boundaries in a way that avoids overlap between them, they automatically
> introduce errors. However, most people do not want to see their
> zipcodes overlapping, so they accept the trade-off.
>
> Secondly, as soon as you generalize an area (which, as discussed above,
> a zipcode really isn't, at least not in the same sense as say a census
> tract) to a point location (such as a centroid), you are accepting a
> generalization. What is a 100% accurate point that describes a
> zipcode? Is it the centroid of the generalized boundary that we chose
> to represent that zipcode? Is it the center of mass of all the
> addresses that make up that zipcode? Is it the location of the Post
> Office that services that zipcode? By accepting a point to represent a
> zipcode, you need to understand the assumptions that come along with
> that. Your data vendor should be able to provide you with a description
> of the methodology that they used to place those points.
>
> Finally, in regards to the many-postal-codes-at-one-point problem, this
> is often the case for US zipcodes. Take for example the case of postal
> codes that represent a PO Box zipcode (the USPS generally takes all the
> PO Box addresses at a post office and assigns them to one or several
> zipcodes of their own). In this case, the data vendor actually does
> have a clue about where to geographically locate those zipcodes. Since
> the PO Boxes are physically located at the Post Office and we have no
> way of identifying where the owners of the PO Boxes actually reside, it
> seems logical to place the zipcode point at the location of the Post
> Office. If you have several zipcodes at a single post office, then
> those points will most likely be coincident.
>
> While I may not have addressed your specific problem, I hope that this
> has been helpful.
>
> Good luck,
> Gary.
>
> Derek Wilson wrote:
>
> > Hi, does anyone have any warnings, comments or concerns regarding
> > data purchased from a vendor. The last postal code point file I
> > purchased had numerous duplications of lat and long values and a
> > number of points were simply not in the right location. When I
> > contacted the vendor to complain, they tried to downplay the
> > inaccuracies. HOWEVER, if someone in our office who had local
> > knowledge of the area had not discovered the errors our client would
> > have considered us at fault. Try explaining to a client "oh, you don't
> > understand. You see there were errors in the data we used to geocode
> > your customers. That's why the locations are off by 3 or 4 blocks, or
> > that's why a number of customers with different postal codes appear on
> > top of each other." AND the thing that really kills me, is that the
> > data vendor made no mention that there data is not 100% accurate. I do
> > know to expect a 100% accuracy is to expect too much, but when you
> > achieve an error rate exceeding 10% then some type of warning should
> > be included with the data you sell. Please let me know your thoughts
> > on my rants,Derek
>
> ----------------------------------------------------------------------
> To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
> "unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
