Dan,

We already have the PAVE product (BM-Win Plus from Hardin-Soft)so what we are starting is our first attempt at the CASS end.

We will be droping any data that we find that we don't need and normalizing the data that we do keep. Until we get into the actual coding, however, it will be hard to tell up front exactly which columns are unnecessary.

For CASS the problem is not so much the PO rules and regulations (that's the big pain in PAVE) but the logic in taking an unknown address which may or may not contain the city, state, or zipcode and cleaning it up, standardizing it, matching it to the national database, and getting the zip+4, carrier route, etc.

In my experience with PAVE and seeing the mailing lists out there, this will be a nightmare.

Thanks agian.

Ed


>Ed,
>
>I think the answer is that none of these vendors distribute the data in the USPS format provided. They probably super-normailize the data. For instance, the core data is really a 9-digit zip code with the house number, pobox or apt# ranges (and a few others I believe). That can then relate to a table of street names with one record for each unique name. Also a city table, state table, etc. And you have to deal with pre and post directionals on the street name, which you probably would want in your parent table.
>
>This would also greatly speed your searches, by the way, since you'd only be searching on a table of maybe 10K records (total guess) to find a matching street name. With that size phonic and near searches would be very easy.
>
>So a main parent structure may look something like this:
>
>zip+4
>zip type (street, pobox, apt floor, company, etc.)
>range start
>range stop
>Even/Odd/Both
>street prefix PK
>street Pre-directional PK
>street PK
>street Post-directional PK
>street suffix PK
>number type (e.g. apt, suite, none)
>Number range start
>Number Range stop
>latitiude (if you need that)
>longitude
>
>That's about 35 bytes/record. And I believe about only 70 million records. That's still larger than you want, but being creative with your normalization, you could probably cut this down further.
>
>5-digit zips do not cross state or city boundaries (as far as USPS addresses are concerned -- they may cross geographic boundaries), so these tables could relate on zip5. Actually I believe the first 2-digits of the zip can tell you the state.
>
>And, of course, you'll need tables for BMCs, SCFs, Post Offices, etc.
>
>I don't envy your attempt to create VFP CASS software. Dealing with all of the USPS regulations is a pain. Plus they change all of the time.
>
>FWIW, we've tested a bunch of the software out there and found PostalSoft's DeakTop Mailer to be the best at presorting. It beat Mailer's by about 5%. We didn't test against Group1 because they were too expensive, but they're supposed to be comparable. Just in case you're looking for competition to test against. Plus they actually get it right when the USPS changes regulations -- unlike Mailer's who usually gets it wrong in the first release.
>
>HTH
>
>Dan
>
>>The data comes from the post office. It is a list of every street, building, apartment, etc in the country and the range of deliverable addresses. It also has information in order to match street nicknames, add the zip+4, add the carrier route, etc. There are a few fields that would not be needed by everybody such as congressional district, county number, etc. For the most part, though, the majority of the fields are needed and it would be the same information distributed by all vendors. The type of software that needs this information is called CASS software and it is used to clean up a mailing list in order to do Automation compatible bulk mail. Some of the vendors of CASS software are Semaphore Corp. (ZP4), MyMailer, Melissa Software (Mailer’s Plus), DataTech (AccuMail), and GroupOne Software.