Using JavaScript, my aim is to create an "intelligent" address search function with a single textbox (rather than separate textboxes for house number, street name, street type, suburb, etc).

I'm attempting to parse the input string entered by the user, to determine which components of the address have been entered. A complication is that users may enter combinations such as:

  • 1 Kent Street Sydney (number, name, type, suburb)
  • 1 King Georges Road Sydney (number, 2x name, type, suburb)
  • 1 New South Head Road Rose Bay (number, 3x name, type, 2x suburb)
  • Kent Street Sydney (name, type, suburb)
  • Sydney (suburb)
  • 2000 (postcode)
  • 275/2/1000 (lot/section/plan)

At the moment I'm breaking the input string into tokens using string.split(" ") and iterating through each token to determine which component it represents.

This is working most of the time (it fails on 1 St Georges Road Sydney), but a colleague suggested I try using a REGEXP to improve the process. I can't see any examples of where this has been done for an address search.

Does anyone have any examples where REGEXP has been used for address validation?

(Note that I'm not actually entering this information into a geocoder at this stage - I just need to break the input string into its component parts, and know what each part represents)

Thanks, Steve

  • PS I'm posting this on the GIS forums rather than general programming forums since I'd expect fellow GIS users to have expertise in this area... – Stephen Lead Aug 9 '11 at 4:30
  • Take a look at Whuber's answer here gis.stackexchange.com/questions/4269/… Also you can search for some other regex answers I seem to remember a few good resources in them. – Brad Nesom Aug 9 '11 at 5:38
  • Brad - I can't see a post by whuber at that URL? And the example given is a simple replace, rather than address-specific. Do you have any better examples? Thanks – Stephen Lead Aug 9 '11 at 5:49
  • Address parsing can get really complicated .. take a look at PostGIS's TIGER geocoding extras: trac.osgeo.org/postgis/browser/trunk/extras/tiger_geocoder – Mike T Aug 9 '11 at 5:54
  • Mike, this is kind of reassuring as I'm following a vaguely similar strategy of iterating over the string trying to decide what each component represents. Maybe I'll just refine what I have, and provide an old-school multi-dialog box if it can't find a result. Thanks for the tip. – Stephen Lead Aug 9 '11 at 5:58

I don't think regular expressions will help you here, because its designed for pattern matching rather than semantic interpretation, so your string.split() function will probably do as well.

But without a database to compare each token against, it'd be pretty hard to determine what level a token represents. If, for instance the right-most token is Zealand, it could be either a country or a province, depending on the next token to the left.

I know you said you've not run it through a geocoder yet, but I would say that was the best way to go. Using Google's Geocoding API, you can pass it addresses formatted in interesting ways and it'll do a good job of returning a properly formatted version of that address.

  • 4
    +1 for making the distinction between syntactic and semantic analysis, which goes to the core of the problem. – whuber Aug 9 '11 at 14:54
  • 1
    @MerseyViking I guess I'm trying to build my own version of Google's geocoder, without their resources or know-how :) Based on the advice above I'll maintain the iteration through the tokens and try to improve on the matching logic. Thanks all – Stephen Lead Aug 9 '11 at 23:27
  • 2
    Be warned, though, you can only use Google's API if you are displaying a Google Map to the user, or else you'll violate the terms of service. – Matt Feb 15 '12 at 20:56

In light of my comment on MerseyViking's answer, I thought I'd elaborate just for clarity and completeness.

I used to work in the address parsing/verification industry for SmartyStreets. What you're trying to do, I think, is called "Single-line address processing" (we call it SLAP). It's a complicated task, though, because addresses will inevitably be very, very different depending on user input, the type of address, and whether or not it is complete or correct.

There are too many factors for a regular expression to solve, as MerseyViking implied. Rather than potentially breaking Google's Terms of Service (otherwise, that was a pretty good solution -- if you don't care that the address is potentially invalid; Google does address approximation, not address validation), I suggest using a CASS-certified service (for US-based addresses) to do this. Since it looks like you may be working with Australian addresses, maybe see if there's a "land-down-under" alternative. SmartyStreets offers international address services that could help you here.

We're developing a fine-tuned algorithm for doing SLAP accurately, and while we tweak it, finish it, and implement it, you might be interested in the rough idea of the algorithm. It is described here in some detail.


This one uses REGEX based US address parsing: http://search.cpan.org/~timb/Geo-StreetAddress-US-1.04/US.pm And it's javascript port: https://github.com/hassansin/parse-address. You can probably do the same for other countries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.