Hi Gary, I was not complaining about a three digit postal code boundary file, but instead the six digit postal code point file, which I was using for a number of cities in Canada. The six digit postal code file should have located a point on the block face of one street segment. That is, I expected all vector segments to have a postal code point assigned to the vector segments midpoint coinciding with the correct street address. Unfortunately a number of postal codes were off by three or four blocks and a couple of them were off by two kilometers. That level of inaccuracy is simply inexcusable. Also I understand that there might be some situations in which a few postal codes may have the same geographic location, however that was not the situation in this case. The main point of my argument is that I bought data in good faith believing it to be accurate. If I was informed or warned that the postal code file had some inaccuracies I could have made a decision to geocode on another data source, e.g., street files, etc. Yours truly, Derek From: Gary <[EMAIL PROTECTED]> To: Derek Wilson <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: February 12, 1999 9:08 AM Subject: Re: MI Re: Just how accurate is that data we spend our money on? >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]
