Structured Address Parsing

[Daniel]

Since the contacts API lamentably doesn't' support structured
addresses for Contacts, what are some potential solutions for parsing
the address? What are y'all using?

I do NOT want to write an address parser its too hard and tricky and a
big tangent from what I'm working on.

I haven't found any open source parser (in java).

One could use GeoCoding services to do this, in fact, Google's own
service seems apt

http://code.google.com/apis/maps/documentation/services.html#Geocoding_Direct

And I was quite excited until I read

1. its a violation of the Terms of Service to use it for anything
other than showing it on a map
2. its a violation of the Terms of Service to use it for a standalone
app
3. you have to call it from a domain, so I'd need to run a middle man
program from a domain to make those requests for all my clients.

Alas.

Thoughts?

[Zindus Development]

Daniel, an excellent question.

The next release of Zindus will have an experimental feature to encode
Thunderbird's address fields as XML in the Google field. Something (but
not exactly) along the lines of this:
http://www.zindus.com/blog/2008/04/30/release-075-and-thunderbird-google-address-sync/

This might be minimally adequate for a few people, but it's unlikely to
work for everyone.

Google: No doubt in the internal Google tech spec for the contacts api
there's a heading titled "Interoperability". Can you drop a hint on
what it says about postal addresses ?

Anyone else?

Leni.

[Daniel]

hehe, I've considered most, if not all, of those options. It makes me
feel better to see other people wracking their brain. I'm also trying
to maintain the gmail "map" link next to the address. If you stick in
labels for "address:1" it breaks mapping, as would xml also, I
imagine.

Using either commas or line feeds works, except you have to assume the
full address is always entered, and I doubt many people use "address
2" so that will throw it all off.

I'm tentatively thinking of going with a comma based solution, with
the requirement you *have* to have all the commas, or it syncs into
the wrong field. So if you just had the City entered, it would be

,,City,Zip,Country

and the full address would be

address 1, address 2, city, state, zip, country

if you remove any of them, you have to leave the , in place. Google
will still map those addresses correctly, it probably ignores
extraneous punctuation.

It's all so dirty. :(

On May 19, 7:46 pm, Zindus Development <google....@zindus.com> wrote:
> Daniel, an excellent question.
>
> The next release of Zindus will have an experimental feature to encode
> Thunderbird's address fields as XML in the Google field. Something (but

> not exactly) along the lines of this:http://www.zindus.com/blog/2008/04/30/release-075-and-thunderbird-goo...

>
> This might be minimally adequate for a few people, but it's unlikely to
> work for everyone.
>
> Google: No doubt in the internal Google tech spec for the contacts api
> there's a heading titled "Interoperability". Can you drop a hint on
> what it says about postal addresses ?
>
> Anyone else?
>
> Leni.
>
> Daniel wrote:
> > Since the contacts API lamentably doesn't' support structured
> > addresses for Contacts, what are some potential solutions for parsing
> > the address? What are y'all using?
>
> > I do NOT want to write an address parser its too hard and tricky and a
> > big tangent from what I'm working on.
>
> > I haven't found any open source parser (in java).
>
> > One could use GeoCoding services to do this, in fact, Google's own
> > service seems apt
>

> >http://code.google.com/apis/maps/documentation/services.html#Geocodin...

[Zindus Development]

Daniel wrote:
> I'm tentatively thinking of going with a comma based solution,

Isn't this fragile? What if there's a comma that has to be part of the
address? eg. Apartment 3,367 Noname st?

> It's all so dirty. :(

Yes. The contrast with the rest of the api is remarkable.

Leni.

[Jeff Nichols]

> > It's all so dirty. :(
>
> Yes. The contrast with the rest of the api is remarkable.

Indeed. Of course the structured name vs. free-form name is also
quite tricky, but it's orders of magnitude simpler than the address
issue.

What really stinks is that Google has the power to do this very
difficult task for us, but we (app developers) aren't allowed to take
advantage of that. Sure would be great if Google added an optional
argument when requesting contact feeds to provide structured instead
of free-form addresses.

Jeff

ps.
I completely understand why Google went with free-form addresses.
They're much nicer for the end-user and Google of course has the
computing, searching and mapping power to handle them. It's just that
most other contact managers use only structured addresses.

[Daniel]

Good point. I think I can either require there be 5 (or X) commas for
the delimiters with a strict rule on how that works, and if it doesn't
match, it all gets shoved into Address 1. I'm syncing to a mobile
device using the PIM model, and there is room in that field for the
full address, it just won't map correctly, and may not work with other
unknown apps either.

[Khash]

Here is my name parsing code in C#:

http://sajadi.co.uk/dflat/2008/05/parse-free-text-to-names/

[Zindus Development]

Just a follow up to this old thread - I filed a bug for tracking purposes:
http://code.google.com/p/gdata-issues/issues/detail?id=1004

Leni.

[Julian (Google)]

This was added as a Feature Request.

Thanks you for the feedback.
Julian.