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
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.
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 ?
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
> 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.
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:
> 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
> > 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.
> 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.
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.
On May 19, 11:13 pm, Zindus Development <google....@zindus.com> wrote:
> 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.
> On May 19, 11:13 pm, Zindus Development <google....@zindus.com> wrote:
> > 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.
