Sorry for any support questions (or Thanks Yous!) that may have been missed due to this problem. I’m trying to recover what I can.

Here’s the problem::

PostCheck uses the USPS Standardization API for standardizing addresses in Address Book. PostChecks send off your address to the USPS servers, which compare the info to their database — filling in missing info and correcting mistakes. The result is sent back to PostCheck which then updates the address.

The results from the USPS are heavily abbreviated, for some unknown reason. Some abbreviations are acceptable and are part of the USPS standards for addressing envelopes. But the results go beyond acceptable. In my latest case, my city is “Middleburg Heights” and the result from the USPS is “Middlebrg Hts”. I can accept that “Heights” is abbreviated, but to abbreviate “Middleburg” by removing the “u” is just silly. This kind of thing happens quite frequently.

You’ll notice, though, that if you search for the same address using the USPS website, that the results are not abbreviated at all.

By default, PostCheck has some basic options enabled that try to undo these abbreviations as much as possible. (The options can be turned of if they cause problems, and perhaps in a future version they will be turned off by default.) The additional problem with this is that, sometimes the results that the USPS provides don’t match up with their list of common abbreviations. So when PostCheck tries to undo the abbreviation, it replaces the abbreviated word with one that matches their list. Usually this works pretty well.

I have tried contacting the USPS technical support department by email in regards to the abbreviations, but I’m not expecting a response. Hopefully the convenience that PostCheck provides outweighs these minor nuisances caused by the USPS. I still use it everyday for my business needs and it still beats Google Maps or visiting the USPS for each address I need corrected.

Let me know if you ever run into special cases that I may be able to work around.

Step 1: Setup iCal

1. Create a new regular calendar in iCal to hold the same events that are in the subscribed calendar. I created one called “Holidays”.
2. I unchecked my “US Holidays” calendar so that they wouldn’t display in iCal.

Step 2: Setup Automator

1. Download the Yellow Camp iCal Automator Actions. (Not sure if the developers’ website still exists. I grabbed my copy from here.)
2. The basics of what the Automator script does: Deletes all events from the “Holidays” calendar and then copies the events from the subscribed calendar, “US Holidays”, into “Holidays”. Pretty simple. It works fast enough for the holidays, but I’m sure there’s a point at which this method doesn’t make sense.



3. I saved my script as an application (in my Library folder, but it doesn’t matter).

*** Note: In the screenshot, I have Automator create a new calendar. This isn’t necessary. You can choose your calendar from the drop-down. I did this because twice my calendar disappeared after deleting the old events and creating a new calendar fixed it and even kept the same color. Since then I just have it move the event to the original calendar and it’s been fine.

Step 3: Setup a Launchd Launch Agent

Note: I’m using Leopard, there may be some differences with Tiger.

The point of this step is to schedule a time to run the Automator action. For my holiday calendars, I’ve set it up to run the first of each month… just in case something was corrected/updated for whatever reason. For other calendars, you might want to update every day, hour, etc. Launchd will also let you update when a file is modified. It might be possible to only trigger the action when your subscribed calendar is actually updated. I haven’t tried this.

I used Lingon to make this easier. (It saved me the hassle of reading the documentation again.) You can also just do it by hand with a text editor. It’s just an XML file.

1. Use Lingon and create a new “My Agents” Launch Agent, or open a text editor and write your own XML. You can see my XML code that Lingon generated here. (I got tired of fighting WordPress to show my code.) I’m not going to document how to use launchd here, Apple has docs of their own.
2. In Lingon’s box #2 or the XML “ProgramArguments” string, you want that to point to the Automator app we saved earlier. Since the application is a package, I had to actually have it point to the executable file in the package - see my code as an example if you don’t understand.
3. If you created this XML file yourself, save it in your Library/LaunchAgents in your Home folder. (It’s important that it’s in the Library in your Home folder.) I saved mine as “com.briantoth.calendarsync.plist”.
4. You’ll need to logout and log back it for the changes to take effect.

When the launch agent script fires (based on your settings) it’ll call your Automator action which will, in turn, update your calendar in iCal. Then when your Mac syncs with MobileMe, it’ll push those changes to your iPhone as well.

The scripts will continue to run, and MobileMe will sync, as long as your account is signed in. If you don’t want your account unprotected while you’re away from the computer, you can either lock the screen, or use Fast User Switching and just bring up the login window without logging-out completely.

Tell me what you think. Any feedback is welcome.

In certain situations, the USPS will return multiple possible correct addresses for the address you’re trying to standardize. This is most common when your address is missing a specific unit number. In some cases, each unit has its own ZIP+4 Code. The USPS returns a default ZIP+4 Code to PostCheck which is not always the correct one for your address.

The 1.8.2 update no longer adds the +4 portion to the ZIP Code when multiple addresses are found, but will still fill in the standard 5-digit code. This is the safer way to go and should make batch-updates more reliable.

Feedback is welcome.