[Feature Request] Structured physical address field

[ArchangeGabriel]

Hi,

One thing that could be useful is structured physical address field, I mean that for storing and edition, an address could be split this way:

Street:
PB:
City:
State:
ZIP code:
Country:

This would help importing contact from Google (see cozy-labs/import-from-google#40) and probably also future features I have in mind, like sorting or searching using those fields (for instance, to answer things like “Who among my contacts leave in Paris?”).

You might also want to implement what Google do, i.e. parsing when someone enters an address using the unique field instead of this detailed ones in order to fill those ones.

Thanks for considering this.

[m4dz]

Hi!

This one is little bit complex, due to the related VCard RFC for addresses. It describes the address field as a complex array of address parts. But I remains difficult to implement properly because worldwide addresses are too differents across all countries. That's why Google stores the address in a single string, and uses its gmap powered engine to parse and interact with the field.

Currently, we have, IMO, 3 options:

• implement the address as a multi-field Ui, which sucks for users (it's really not intuitive to use) and do not match all use-cases for worldwide addresses
• use a single multilined input and parse it later for storage and interactions, which suppose to use a library that can do the parse (and I haven't find a good one at this time)
• use a 3rd service to parse the data (such as address doctor) and sanitize it, which is irrelevant in the Cozy context (your data must not go outside of your Cozy without your consent).

So, we only have the 2nd alternative at this time, but I haven't find a good libary to do this (maybe using osm related project?). If someone knows a good one, or imagine a better solution, I'll be happy to discuss about it 😄!

Thanks again @ArchangeGabriel for your suggestion. It's definitely something we must handle in the app, when we can find a good way to do it.

[ArchangeGabriel]

You’ve probably found those things already, but just in case there are some discussions here:
http://stackoverflow.com/questions/11160192/how-to-parse-freeform-street-postal-address-out-of-text-and-into-components (and all the mentioned links in OP)

Also a bit here (not linked from the former):
http://stackoverflow.com/questions/16413/parse-usable-street-address-city-state-zip-from-a-string

[ArchangeGabriel]

And the most relevant part I think:

You'd need some code that really understands addresses, and if that code does exist, it's a trade secret. But you could probably roll your own if you're really into that.

[clochix]

Thanks @ArchangeGabriel, we'll have a look at your links when we'll work on the feature.

[f6fvy]

IMHO, having a multi field UI is not so bad. 2 or 3 address fields + city + zip + state/prov + country do the trick for the vast majority of places worldwide. It works this way for my address book on Android and Thunderbird, and so many e-commerce websites.

Having an automatic parser is probably sexier, but in the meantime, please consider the above solution.

[m4dz]

A possible implementation for address formating: https://github.com/OpenCageData/address-formatting