Re^3: Extracting a (UK) Address

I have little to add to the other suggestions already made. I think it is unlikely you can home in on the address without it being delimited in some way.

The example above clearly delimits with "VAT No:" and "DESCRIPTION". I think you'll need to know what variations the invoices have had over the years and code for all of them.

Other tricks might help,

e.g. is there always a titled name (Mr,Mrs,Miss,Ms etc.) at the start of the address ?, If so analyze all the names in your dataset to identify all unique titles.

177 Elm Road, is the only line that starts with a number so the address is in that block

Address lines are the only ones that end with a comma, so use that block

The address is always in the first n lines of the invoice ?

The address always has a county in it ?

etc.

Also if you have access to postcode validation (database ?) that could help

Whatever, I assume you will end up with many invoices that can't be correctly handled, so you'll need to agree how to handle those exceptions.

Comment on Re^3: Extracting a (UK) Address

Replies are listed 'Best First'.
Re^4: Extracting a (UK) Address by Marshall (Canon) on Jan 03, 2009 at 19:55 UTC
This idea looks like it is in the right direction. If the address you seek is between a VAT line and a DESCRIPTION line, and that's the way that it always is, then, something like this might help? This code looks for non-blank lines between and including lines starting with VAT and DESCRIPTION. So throw away those lines and any blank lines. The "trick" then comes down to figuring out when the address ends. If it is possible to write a simple regex that fits a UK postal code, then no state machine is required (when you see the postal code, the address record is done). Below I threw in an extra line feed when I see the postal code. Many variations are possible! Anyway, just an idea for you... Maybe this doesn't work if postal code is too variable and of course you'll have to refine my regex... But maybe this will spark another idea? while (<DATA>) { if (( /^VAT/.../^DESCRIPTION/) && (!/^s*$/)) { next if /^VAT/; next if /^DESCRIPTION/; print; #these are the address lines print "\n" if (/\w+\d \d/); #the trick is to see #when address is done, eg a postal code } } __END__ prints: Miss Carol Hocker 177 Elm Road, Brighton East Sussex BN2 7HB Mr Whatever 177 Elm Road, Brighton East Sussex BN2 7HB __DATA__ Invoice Invoice No: C0331-2008 Invoice Date:27/02/2008 VAT No: 679 7113 03 Miss Carol Hocker 177 Elm Road, Brighton East Sussex BN2 7HB DESCRIPTION blah..blah Invoice No: C0331-2008 Invoice Date:27/02/2008 VAT No: 679 999 03 Mr Whatever 177 Elm Road, Brighton East Sussex BN2 7HB DESCRIPTION ...something here.... [download]	[reply] [d/l]
Re^4: Extracting a (UK) Address by DrHyde (Prior) on Jan 05, 2009 at 11:08 UTC
e.g. is there always a titled name (Mr,Mrs,Miss,Ms etc.) at the start of the address ?, If so analyze all the names in your dataset to identify all unique titles. 177 Elm Road, is the only line that starts with a number so the address is in that block Address lines are the only ones that end with a comma, so use that block The address is always in the first n lines of the invoice ? The address always has a county in it ? I would assume that there isn't always a title - invoices are often addressed to a company, or to "The Mumble officer". Addresses don't always include a number. Some houses only have names. eg, Mumble Farm, Mumblevillage, Kent Address lines don't always end in a comma - although that at least should be consistent in any particular version of an application. Should. Unless addresses were entered manually in a multi-line text box. Addresses don't always have a county in them. The county is no longer required. And you won't have a post code for all addresses. The solution in this case is to look for whatever is between "Vat No: blahblah" and "description". In the general case, you're buggered, because you can't tell the difference between this: My new address is as follows. Please send all correspondence to: Tottenham Hotspur, Edinburgh Rd, Bexhill. Blah blah blah blah (yes that's a real address - someone who lives near my parents named his house after the football club. and this: In my address to the society I looked at the apparent links between: Tottenham Hotspur, Edinburgh Road, Bexhill. I used them to demonstrate the difference between correlation and causation. The solution we adopt where I work to a somewhat similar problem is to have the machine look for the data and attempt to parse it, but to show a person the data in context before committing it to the database. This is much quicker than having a person find/highlight/cut/paste the data, while still having reasonable quality control. Where the computer gets it right, it's a lot faster than a person, and where the computer gets it wrong, a person can fix it.	[reply]