Country.zip Party.address - Having more than one subdivision (diff types). Refs to country.zip

I have extended country.zip to have a second subdivision (subsubdivision). In the case of Spain it make sense and the data is there to be imported with the script without issues.
Example (subdivision: Catalunya, subsubdivision: Barcelona).

I also added coordinates (latitude, longitude and accuracy). Again the data was there to be imported.

I do not know if the community would like to have this data available officially.
I do not know if it make sense for other countries.

The initial import with the script (minor modifications) is easy, update on existing data may not be that easy.

1 Like

Indeed of adding a second field, I think it is better to make an option to choose which code level should be imported. As far as I can see we do not make any use of the subdivision field and it will go in the same direction as Issue 7554: Allow to customize the type of subdivision used per country - Tryton issue tracker

I guess that in the real world a Zip can have 0 or N subdivisions and in this o2m I reckon there is a constrain that a zip cannot have two subdivisions of the same type.

Choosing one subdivision or another on import is choosing to import a partial information.
When I look at zips in Spain both ‘autonomous community’ and ‘province’ are important.

I don’t know much about other countries subdivisions and zips, but looking at the data in country.subdivision I see many countries that have more than one type of subdivision.

But as the province is part of an ‘autonomos community’ having the more detailed information give you the full detail.

That’s why subdivision is a tree with parents and childrens. So you can choose the more specific subdivision and now all the information about them.

1 Like

Ups, yep I only need one subdivision. If I change the import I guess I will find out about the issue 7554, sorry it took a bit to understand.

There is no such constraint. You can have multiple times the same zip/city that point uses different subdivisions.
But I’m wondering if you are not using the zip as referential data. It can not be used for that because they are deleted before being imported.

With my proposal, you will choose the level you want. We have no guarantee that we have all the level of subdivision that geonames provide.

Ok, I think that now I understand a possible reason why address doesn’t have a reference to zip.

Could I deactivate old country.zips (deleted or change) and create new ones as needed on each import? Not sure if I will have to keep a copy of the last imported file to do this.
Could I change the import if I really want to make reference to country.zip or would I end up with other issues that I cannot foresee?

The model was never designed to be referential data so we can not guarantee such usage in the future.

1 Like

Is this model only intended as a helper containing data for auto-completion for address?
Am I better off creating my own zip model if I want a referential zip model?

Yes.

Probably as zip can be deleted.

I don’t like to add more fields in party.address model.

Since issue5563 has a domain strict that only can select a subdvision with parent is None. Some cases we need to select a subdivision that parent is not none (for example, Barcelona and not Catalonia)

country_zip_es module remove this domain to allow select all subdivisions by country (Barcelona, Tarragona, Girona…).

In case like to print subdivision and the parent subdivision, you could custom reports or get_full_address method to append parent subdivision (subdvision.parent.name if subvision.parent else ‘’)