Modular approach to person groups

[schakalakka]

Find a modular easy adaptable approach for the person groups. The synthesizer tool should not export the preson groups but specific person attibutes from which the person groups can be derived. Because each researcher/institute/country could have different measures the method should be easily editable.

Keep in mind the DiaryAnalyzer versions and the person groups derived from the MiD.

[schakalakka]

Two ways of person groups are implemented in the branch modular_person_groups2:

1. Using the attributes sex, age, status from the person and cars and has_child from the person's household
2. Using the group column in the region_persons table. The attributes (from 1.) belong still to the person group instance (in TAPAS) but the group assignment is entirely done by the group column/integer. The attributes may or may not match.

We use a parameter flag FLAG_USE_GROUP_COLUMN_FOR_PERSON_GROUPS to determine which one of the two ways is used. If true we use the second approach. Default is false.

Example: FLAG_USE_GROUP_COLUMN_FOR_PERSON_GROUPS=false A working woman, age=35 with a car belongs to person group 11 (EWT45mP W). FLAG_USE_GROUP_COLUMN_FOR_PERSON_GROUPS=true If you assign group=1 to this person in region_persons, this person is going to be a pupil disregarding its attributes.

[schakalakka]

Still to do is the edit the sql function (in the installer and the db) create_region_basdtables (remove the p prefix) and the inserts in the sql dump zip in berlin_persons.

Additionally if approved the global_person_codes table must be changed.

[schakalakka]

modular_person_groups2 branch merged into master

The global_person_codes changed according to the new design. For now we save the old version in global_person_codes_bak

Db functions still need to be edited (probably) but this is linked to #32