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.
The typology of statistical units changes is exhaustively described in . 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
territorial change or a
For each significant type of a unit's change the following sections specify the label to use
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 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 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.
Following the nomenclature of territorial units events (, page 148), the changes of statistical units may be represented as follows.
Merge changes happen when two or more units of the previous version are merged into another one. They must be labelled with "merge" keyword.
The resulting unit may be a new unit:
GU1 merges into GU3
GU2 merges into GU3
The resulting unit may be one of the units that participated in the merge:
GU2 merges into GU1
GU1 is changed by merge
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:
A split change can cause the original unit's termination:
GU3 is split into GU1
GU3 is split into GU2
If the original unit is not terminated in the new version, this is a case of extraction:
GU3 is changed by split
GU3 is split into GU4
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:
GU1 terminates by reallocation
GU2 changes by reallocation
GU3 is created from reallocation
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:
GU1 changes by rectification
GU2 changes by rectification
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.
changes sheet must respect the layout shown in Table 2.9
(examples of values are given in italics).
changes sheet layout example
Details on the columns are given below:
MANDATORY (except for a new unit, e.g. when the change cell value is one of
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.
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.
MANDATORY (except for a termination, e.g. when the change cell value is one of
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).
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.
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:
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 event.
Code change event.
Territorial change event.
Territorial change event caused by a merge.
Territorial change event caused by a split.
Territorial change event caused by a redistribution.
Unit termination event.
Unit termination by merge event.
Unit termination by split event.
Unit termination by Unit termination by redistribution event.
Data constraints. Any combination of
change is unique in this table.