2.6. Changes Sheet

The changes sheet is mandatory only if the nomenclature to integrate represents a new version of a nomenclature already supproted by the Database. This sheet tracks the changes that characterize the new version as compared with the previous one.

Before introducing the template of the sheet, the typology of statistical units evolution is presented here in order to explain the conventions to use.

2.6.1. Typology of Statistical Units Evolution

The typology of statistical units changes is exhaustively described in [2]. The present section makes a brief introduction into it, with a certain adaptation to the ESPON database implementation.

Generally, there are three types of changes or events that may occur to a statistical unit during its evolution in a nomenclature. This may be an existential change, a territorial change or a non-territorial one.

For each significant type of a unit's change the following sections specify the label to use in the changes sheet.

Existential Changes

Existential changes concern life events in a unit's history. They occur when a statistical unit is created or terminated.

A statistical unit is considered to be created when it appears for the first time in the list of statistical unit of the nomenclature. It is considered to be terminated when it disappears from this list.

The creation of a unit may be absolute. This is the case when a new territory is added to the nomenclature, where no units existed before, or when it is impossible to determine which units of the previous version served as ancestors for the new unit. This type of the unit's creation must be labelled "new unit".

It can also be relative. It occurs when the new unit results from the modifications applied to the units that already existed in the previous version of the nomenclature.

The termination of a unit may be absolute. This is the case when a part of territory has been excluded in the new version of the nomenclature, or when it is not possible to determine which units appear in the new version in the area formerly occupied by the unit that was terminated.

It can also be relative. It occurs when new units are created in the area of the previous one, that is to say that the disappearing unit is an ancestor for one or more unit being created in the new version.

Territorial Changes

Territorial changes occur when the territory of a unit is modified, but the unit still exists in both the versions of the nomenclature. It continues to be considered as the same entity.

As for existential changes, territorial ones can be absolute and relative.

An absolute territorial change occurs when the bounds of the area covered by the unit is completely shifted, without intersecting with the previous territory. This case is very rare, but can occur theoretically.

A relative territorial change occurs when modifications are made on the unit and its neighbors, so as the bounds are no more the same in the new version.

Non-Territorial Changes

Non-territorial changes occur when the unit is still considered as the same entity as in the previous version, but its name or code change in the new version. These changes are not accompanied by modifications of the unit's area.

A code change usually happens when the nomenclature incurs a harmonization after a series of modifications in previous versions.

A name change can happen between any versions and may be caused by different factors of historical, political, economic or other contexts.

Code and name changes may occur separately or simultaneously. In the first case, they must be labelled "code change" and "name change" respectively. In the second case, they must be labelled "code and name change".

Code and name changes are tracked only if they represent independent events, happening without existential changes of the unit. In fact, an existential change already implies a code and a name creation and termination.

Statistical Units Changes Case-by-Case

Following the nomenclature of territorial units events ([2], page 148), the changes of statistical units may be represented as follows.

  1. Merge changes happen when two or more units of the previous version are merged into another one. They must be labelled with "merge" keyword.

    1. The resulting unit may be a new unit:

      The description of these changes is the following:
      • GU1 merges into GU3

      • GU2 merges into GU3

      This description is minimal and sufficient to deduce that GU1 and GU2 are terminated by merge (relative termination) and GU3 is a new unit created from merge (relative creation).

    2. The resulting unit may be one of the units that participated in the merge:

      The description of these changes is the following:
      • GU2 merges into GU1

      • GU1 is changed by merge

      This description is minimal and sufficient to deduce that GU2 is terminated by merge (relative termination) and a relative territorial change (by merge) occurred to GU1.

  2. Split changes happen when a unit is divided into two or more units in the new version. They must be labelled with the "split" keyword.

    Several cases of split change are described below:

    1. A split change can cause the original unit's termination:

      The verbose description is the following:
      • GU3 is split into GU1

      • GU3 is split into GU2

      This is minimal and sufficient to deduce that GU3 is terminated by split (relative termination) and that new units GU1 and GU2 are created from this split (relative cretion).

    2. If the original unit is not terminated in the new version, this is a case of extraction:

      The verbose description is the following:
      • GU3 is changed by split

      • GU3 is split into GU4

      This is minimal and sufficient to deduce that GU3 is changed by split (relative change) and that a new unit GU4 is created from this split (relative creation).

  3. Redistribution changes happen when at least one original unit continues its existance or disappears and partial territorial changes are made to all the units concerned. These cases are mixed situations of merges and splits, when it is difficult or impossible to define the main characteristics of the change. These changes must be labelled as "redistributed".

    If a territorial change happens to two or more units, at least one of them disappears or at least one new unit appears in the new version, this is a reallocation change:

    The description of these changes is the following:
    • GU1 terminates by reallocation

    • GU2 changes by reallocation

    • GU3 is created from reallocation

    This description is minimal and sufficient to deduce that GU2 is changed by reallocation (relative change), GU1 is terminated by reallocation (relative termination) and GU1 is created by reallocation (relative creation).

    If the territory of two or more units has been revised in the new version, but no units disappeared, neither appeared in the new version, it is the case of a rectification change:

    The description of these changes is the following:
    • GU1 changes by rectification

    • GU2 changes by rectification

    This description is minimal and sufficient to deduce the respective relative territorial changes.

2.6.2. Changes sheet table example

The case-by-case analyzis made in the previous section allows to create a pattern to follow in order to make the trace of the nomenclature evolution. The example below cites the changes seen between NUTS 2006 and 2010 versions.

The changes sheet must respect the layout shown in Table 2.9 (examples of values are given in italics).

[Important]

To be parsed and taken into account, the changes sheet requires a non-empty value for the version_previous field of the version sheet.

Table 2.9. changes sheet layout example

 ABCDE
1unit_code_previousunit_level_previousunit_code_thisunit_level_thischange
2DE412DE402merge
3DE422DE402merge
4GR0EL0code change
5IE0243IE0243name change
6GRZ1ELZ1code change
7GRZ1ELZ1name change
8ITC453ITC4C3split
9ITC453ITC4D3split

Details on the columns are given below:

unit_code_previous

MANDATORY (except for a new unit, e.g. when the change cell value is one of created, created from merge or created from redistribution).

References the code of the changing unit of the previous nomenclature version. It must be one of the unit codes already present in the version of the nomenclature supported by the Database.

unit_level_previous

MANDATORY

References the level label of the changing unit of the previous nomenclature version. It must be one of the unit levels already present in the version of the nomenclature supported by the Database. An empty value references the default level of a non-hierarchical nomenclature.

unit_code_this

MANDATORY (except for a termination, e.g. when the change cell value is one of termination, split, or redistribution).

Contains the code of the unit of the described version of nomenclature. It must be also present in the units sheet (see Section 2.3).

unit_level_this

MANDATORY

References the level label of the changing unit in this nomenclature version. It must be one of the unit levels declared in the version sheet. An empty value references the default level of a non-hierarchical nomenclature.

change

MANDATORY

Contains the literal (case-unsensitive) corresponding to the type of the change produced, previously described in the subsections on the typology of changes. Two simultaneous changes (example: the code change and the name change) must be mentioned on two lines (see lines 6 and 7 in Table 2.9). The expected literals are:

created

New unit creation event.

created from merge

New unit creation from merge event.

created from split

New unit creation from split event.

created from redistribution

New unit creation from territorial redistribution event.

name change

Name change event.

code change

Code change event.

territory change

Territorial change event.

territory merge

Territorial change event caused by a merge.

territory split

Territorial change event caused by a split.

territory redistribution

Territorial change event caused by a redistribution.

termination

Unit termination event.

merge

Unit termination by merge event.

split

Unit termination by split event.

redistribution

Unit termination by Unit termination by redistribution event.

The line is rejected if the value in this column is not one of this enumeration.

Data constraints. Any combination of unit_code_previous + unit_code_this + change is unique in this table.