On Sep 11, 2011, at 6:16 AM, Udo Spallek wrote:

> Hi,
> Cédric Krier <[email protected]>, Sat, 10 Sep 2011 11:36:12 +0200:
>> On 09/09/11 20:58 -0700, Bruno (Thymbra) wrote:
>>> Hi,
>>> Contributing use autocomplete fields, to have validated data,
>>> always seems to me an excellent idea. As Udo Spallek proposes, to
>>> provide modules with xml data like the chart of accounts, it was my
>>> intention in writing the module country_ar.
>> Such modules could be integrated in Tryton only if we got an reliable
>> way maintain the list of cities, like we have with countries.
> I don't think there is reliable data for world wide post codes[1].
> Post codes seems often to be semi-official like the data we actually use
> for the charts of accounts. If we really want/need this data in Tryton
> we should support free sources like geonames[2][3] or openstreetmap. 
> 
> But do we really want to provide and maintain a static duplication of
> this kind of data within Tryton? I think not.

I don't think we should maintain a static duplication, intact we have already 
seen the shortcomings of such static duplication in our country and subdivision 
database (which is based on an ISO standard and still silly).

We were hit with the same problem last week in the Brazilian context and we 
immediately ruled out the option of storing static data in tryton because 
Brazil alone had over 760 K known post codes. So we decided to build a web 
service which would return the details against the post code on a HTTP GET. 

> 
>>> Be a matter of doing some testing with your proposal and check if
>>> it matches the problem in my country.
>> I only do a design proposal, I really don't know if I will have time
>> to work on the implementation but anybody can implement it.
> We could extend the party module with the functionality to save
> given tuples of zip(postal code), city, subdivision and country. This
> will help the users anyway, because they always need to encode these
> information only once. 
> 
> But what exactly should be the functionality? 
> 
> * Is it for looking up city and nation names by postal codes? 
> * Is it for reverse looking up postal codes by cities?
> 
>  * Looking up postal codes depends at least in Germany from city, 
>    street name and house number (See e.g. the table in [4],
>    'PLZ' is the postal code). Openstreetmap address this
>    problem by collecting pairs of geo-location and postal code. So
>    things can get complicated for reverse lookup.
> 
> * Or is it both?

I don't think this can be consistent amongst all service/post codes. For 
example [1] Brazil offers resolution of post code to the street while Indian 
post code resolution ends with a  Post Office region (Kind of ID for a post 
office).

So I am really not sure how this could work in a multi country scenario. 
Perhaps chose the web service based on country (sent in values dictionary by 
autocomplete).

[1] A sample lookup on the web service we built for Brazilian post code lookup: 
http://cepsearch.com/api/search?cep=11040-050

Thanks,

Sharoon Thomas
Director & CEO, Openlabs Technologies & Consulting ℗ Limited
Regd Office: 2J-Skyline Daffodil, Trippunithura - Kochi - IN 682013

Mobile:  +1 786 247 1317
http://openlabs.co.in

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to