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]
