Address formats
Posted on 18 Jun 2009 at 11:48
Simon Jones tackles the tricky subject of handling addresses in applications, both within the UK and far beyond.
I can't say that these kinds of rules mattered very much to the application I was working on, as I was more concerned with the order in which the different parts of the address are presented and where the line breaks should fall. When writing to addresses within the UK, you wouldn't want to include the country, while when writing to addresses in France you need to put the ZIP code on the same line before the post town; when writing to the US, the ZIP code goes on the same line as the post town at the end, after the state abbreviation.
Most European countries, plus many others worldwide, follow the same rules as France, while others follow the US example. Some use the UK format, but you'd have to add the country at the bottom of the address to ensure correct delivery.
After reviewing the rules given on the UPU website, I decided I needed a table of address formats that set out the elements in order and specified the line breaks between elements, and then each country entry could point to the relevant address format to be used for addresses in that country. I decided to give the names Street, City, State, Zip and Country to the components of the address, and CR to mark where each carriage return should be placed. Separating these names with semicolons makes these address format records easy to parse and iterate through their parts, then output the correct part followed by a space or start a new line. Some of the formats are shown in the table below.
I gave each format a simple name that includes a quick reminder of what the format involves. Now whenever the user types in an address, they must first enter the country, which is used to pick the correct address format - I can then present a live preview of how the address will look as they enter the other parts. Whenever I need to display an address onscreen or print it on paper, I can pass the various parts of the address to a single central function that returns the address formatted correctly for the country concerned.
This scheme comes into its own when using Mail Merge to send the same form letter to tens, hundreds or thousands of people. Our application can output the data in CSV format, including the formatted address, and pass this on to Word to be used as a data source for the merge operation. The user just puts a <
Using postcodes
UK postcodes are among the most computer-unfriendly inventions of the modern world. A mishmash of letters and numbers with six quite distinct patterns and many annoying exceptions, they can't be sorted into meaningful order, and there's little if any geographical relationship between numerically adjacent codes: in Glasgow, for instance, the G60 district sits between G81 and G82 to the west of Clydebank, while G73 sits between G32 and G44 on the south-east of the city, and G40 is separated from G41 and G42 by both G5 and G73! Without mapping data it's impossible to infer these topological relations from the postcodes alone.
The only way to fully validate a postcode is to compare it against the full list of 27,000,000 addresses in the Postcode Address File (PAF), which Royal Mail maintains and sells. It charges £1,700 to £3,250 per year for this data and then £85 per year for each user, while corporate licences cost up to £75,000 per year. Other countries make their postal code databases available for free, so that the more postal codes are checked the more correct they'll be, which makes sorting and delivering the mail more efficient. Royal Mail appears to want to go in the opposite direction by making money out of the data, despite the fact that restricting access to it may hinder its main operation. Royal Mail made a profit of £1.58m in 2007 on revenues of £18.36m from licensing its PAF data. What will happen to the PAF data if Royal Mail, or part of it, is sold off? Many people are calling for the data to be "liberated", rather than given away to whomever buys (into) Royal Mail.
Simon Jones
Simon is a contributing editor to PC Pro. He's an independent IT consultant specialising in Microsoft Office, Visual Basic and SQL Server.
advertisement
- Getting to grips with Microsoft's IT Health Environment Scanner
- Virtualise your servers
- The changing face of travel gadgets
- Build your own distributed file system
- The bulletproof Dell that costs an arm and a leg
- Microsoft Office 2010 Technical Preview: Q&A
- Lawnmowers, the TyTN II and one odd insurance request
- There'll never be a bulletproof OS
- How far can we trust apps?
- Five nice touches in Outlook 2010
- Why Britain's watchdogs have fewer teeth than goldfish
- Tabbed documents: how to make Office 2010 great
- Outlook 2010 People Pane – does it spell death to Xobni
- Microsoft Outlook 2010 screenshots
- Co-Authoring in Word 2010 and SharePoint Foundation 2010
- Microsoft Outlook 2010 screenshots: Backstage view
- Flash 10.1: Developing for Desktop and Device
- Microsoft Office 2010 screenshots: Recover unsaved items
- Microsoft Word 2010 screenshots: Text Effects
- Microsoft Word 2010: inserting screenshots
- Q&A: Why Conficker was a victim of its own success
- App developers losing faith in Android
- Biz Stone: Murdoch's Google veto will "fail fast"
- Google adds automatic captions to YouTube
- China ramps up cyber spying
- Mozilla maintains dependence on Google
- Windows 7 flying off the shelves
- Google Chrome OS: full details unveiled
- AOL slashes 2,500 jobs
- YouTube begins streaming full-length shows
advertisement
Printed from www.pcpro.co.uk


