Prof. Dr. E. Vanhaute
Torsten Wiedemann
Universiteit Gent
Nieuwste Geschiedenis
Blandijnberg 2
9000
09/264.40.40 / 40 14
Construction of a GIS for the
territorial structure of Belgium
Description
of the database (overview)
1. Map of “least common geometry”
1. Map of least common geometries
2. Constructyion of a relational, tempo-spatial MS-Access database
Data –
tables at municipality level
Construction of an interface and
possible applications
example b: Boundaries of
municipalities
Example c: Districts and Departments
Example d: Calculation and
visualisation of the population density and evolution
Construction
of a GIS for the territorial structure of Belgium
In what follows, the technical construction of the
Belgian historical geographical information system will be described. This is
the underlying database, which is NOT accessible via internet. The maps, which
can be consulted via our website are derived
from the original database.
Introduction
Between 1993 and 2000 research has been carried
on the subject of the territorial structure of
Based on the resulting collection of maps and
data a GIS has been constructed since 2001 to make these data available for
scientists. Furthermore the possibility had to be created to link additional
data to the database in an efficient way.
At present
the database contains the following information:
a) A single map, containing all
boundaries of Belgian municipalities for each census year between 1800 and
1961, for 1963 and for present day. Accuracy: 10m RMS for the present day
boundaries, 50m RMS for the municipalities in 1963 (this map has been reconstructed,
based on the statistical neighbourhoods in 1981, +/- 250m RMS for the
boundaries of municipalities which vanished before 1963 (the historical
boundaries before 1963 have been digitized “on sight”, based on historical maps
and literature). The boundaries have been georeferenced
to the Belgian Lambert 72 map projection. The map has been stored as an ArcView shapefile.
In a database, powered by MS-Access XP, the
following data have been stored in a relational database structure, which makes
it possible to link all data to map units. Thanks to the hierarchical structure
of the Belgian administrative units, the map of the municipality boundaries can
also be used to reconstruct territorial units at a higher level, such as
departments and districts, since these units are assembled of different
municipalities.
b) The name of every Belgian municipality since
1800.
c) A linktable for
the composition of the Belgian departments between 17.02.1800 and 31.12.1963:
Districts and municipalities per department.
d) A linktable for
the composition of the Belgian districts between 17.02.1800 and 31.12.1963:
Municipalities per district. From this table the datum’s for the creation and
for the abolition of each municipality can be derived. The datum’s for the
abolition of municipalities after 1963 have been stored in a separate table.
e) A linktable for
the composition of the Belgian cantons (juridical and electoral) between
17.02.1800 and 03.04.1965: Municipalities per canton).
g) Names, datum’s for creation and abolition of
each department, district, electoral canton and juridical canton.
h) The number of inhabitants for each census
year between 1800 and 1961 and in 1991 and 1998.
i) The data on land use in 1834 (per
municipality: cadastral surface per land use category.
j) Industry in 1846, 1880, 1896, 1910 (per
municipality: employment per sector).
Description
of the database (overview)
Figure 1 Related tables in the MS-Access database
a) tbl_linktable (link between map and municipalities)
a.
NIS_code (municipality-id)
b.
Poly_id (polygon-id)
c.
Begin
(yyyy, year when a certain NIS_code/Poly_id
relation became valid for the first time)
d.
End
(yyyy, year when a certain NIS_code/Poly_id
relation was not valid anymore)
b)
tbl_nis_gem (Municipality names)
a.
Volgnummer (internal identifier)
b.
NIS_code (key of this table)
c.
NISOUD
(original, official identifier, used by the Belgian administration in the past)
d.
Name
(Name of Municipality, according to local preferences: Dutch in Flemish region,
French in Walloon region)
c) tbl_arr_gem (link between districts and municipalities)
a.
Arr_code (district-key)
b.
NIScode (municipality-key)
c.
Begin
(datum: dd/mm/yyyy, from this datum on a particular
relation Arr_code/NIScode becomes valid)
d.
End
(datum: dd/mm/yyyy, from this datum on a particular
relation Arr_code/NIScode is not valid anymore)
d) tbl_link_arr_prov (link between departments and districts)
a.
Provinciecode (department-key)
b.
Adminarrcode (district-key = Arr_code)
c.
Begin
(dd/mm/yyyy)
d.
End
(dd/mm/yyyy)
e) tbl_administratieve arrondissementen (names of districts and datum’s
of existence)
a.
Arr_code (district-key)
b.
Naam (district-name)
c.
Begin
(datum of creation: dd/mm/yyyy)
d.
Einde (datum of abolition: dd/mm/yyyy)
f)
tbl_departementen en provincies (names of departments and
datum’s of existence)
a.
Prov_code (department-key)
b.
Naam (department-name)
c.
Begin
(datum of creation: dd/mm/yyyy)
d.
Einde (datum of abolition: dd/mm/yyyy)
g)
tbl_gkanton_gem (link between juridical cantons and
municipalities)
a.
gkant_code (juridical canton-key)
b.
NIScode (municipality-key)
c.
Begin
(dd/mm/yyyy)
d.
End
(dd/mm/yyyy)
h)
tbl_gerechtelijke kantons
(names of juridical cantons and datum’s of existence)
a.
gkant_code (juridical canton-key)
b.
Naam (juridical canton-name)
c.
Begin
(datum of creation: dd/mm/yyyy)
d.
Einde (datum of abolition: dd/mm/yyyy)
i)
tbl_kkanton_gem (link between electoral cantons and
municipalities)
a.
kkant_code (electoral canton-key)
b.
NIScode (municipality-key)
c.
Begin
(dd/mm/yyyy)
d.
End
(dd/mm/yyyy)
j)
tbl_kieskantons (names of electoral cantons and datum’s of
existence)
a.
gkant_code (electoral canton-key)
b.
Naam (juridical canton-name)
c.
Begin
(datum of creation: dd/mm/yyyy)
d.
Einde (datum of abolition: dd/mm/yyyy)
k) tbl_nis_new_oud (translation:
NIS-code/original NIS-code)
a.
NIS_code (municipality-key)
b.
NISOUD
(NIS code before 1980)
c.
Name
(municipality-name)
d.
Arr_code (present district)
l)
tbl_area_LCG (area’s of the poygon’s
of the LCG-map. This table is used to calculate the total area for each
territorial unit at each possible moment in time)
a.
CEN_NAME2
(polygon-id = Poly_id in linktable)
b.
Area
(m² per polygon)
m)
tbl_population (population per municipality per census year
1800-1961, 1991, 1998)
a.
NIS_code (municipality-key)
b.
Population
(number of inhabitants)
c.
Begin
(census year)
d.
End
(year of next census)
This table illustrates the
possibilities to integrate data within the historical geographical database.
Other data (land use, agriculture and industry) are stored in tables with the
same structure as “tbl_population”. Through the
combination data/NIS_code all kind of data can be
linked to “tbl_linkltable” and to the map of least
common geometry. Thus all kind of data can be visualised geographically.
n)
tbl_lambertcoordinaten (These data have been bought form a
commercial company).
a.
NIS_code (municipality-key)
b.
Volgnummer (auto number)
c.
NIS_nr (official NIS code)
d.
Name
(municipality-name)
e.
ARR
(present day district-code)
f.
Gemeenten (municipality names in different languages (Frans/Nederlands))
g.
X
(X-co-ordinates in km(!))
h.
Y
(Y-co-ordinates in km(!))
o)
tbl_gem_website (addresses of websites: www.[gemeentenaam].be,
the URL has been generated automatically and there is no guarancy
that the URL exists)
p)
tbl_fusie_deel
a.
b.
Fusie (name of present day municipality)
c.
Nummer (original
d.
Deel (name of the assembling municipality)
e.
Datwet (datum of merge (dd/mm/yyyy))
Technical
background
The core of the GIS for the Belgian territorial structure consists of
three modules:
1.
Map
of “least common geometry”[2]
This LCG-map consists of polygons, delineated by all boundaries
which have ever existed (between 1796 and 1963 and in 2003). Each polygon is
described by a unique polygon-id in the database.
2.
Linktable
This table contains 4 fields:
-
Polygon-id
This is the polygon-id for
the polygons of the LCG-map.
-
NIS-code
The NIS-code is an identifier for all municipalities which
have ever existed on Belgian territory between 1796 and now. Naturally, there
is a 1-to-1-relationship between the NIS-code and each municipality. For some
historical municipalities no official NIS-code has been established. Therefore
a virtual NIS-code has been generated, based on the key codes of present day
statistical neighbourhoods. The table “tbl_nis_new_oud” contains the translation for the official NIS-codes
into virtual NIS-codes.
-
Begin-tijdstip
This is the year (yyyy) from
which on a particular polygon was part of a municipality, described by the
“NIS-code” in the same record of this table. If a boundary has been changed on
-
Einde
This is the year (yyyy)
until when a particular polygon was part of a municipality, described by the
“NIS-code” in the same record of this table. If a boundary has been changed on
Each pair “NIS-code/Polygon-id” is valid from “begin-tijdstip” till “eind-tijdstip – 1 jaar”.
In fact the table is only useful to describe the situation on December 31st of
each year. In the future an update of the data has to be performed to realise a
higher temporal resolution of the database.
3.
Attribute
data
These data are linked to the different territorial entities. All data
have to be linked to the same NIS-codes as processed in the linktable.
Furthermore all data are valid for a certain period in time or for a particular
moment in time. Therefore all data tables contain fields such as “begin”, “end”
or “datum”.
Data which can not directly be linked to a particular municipality (for
example data per district) can indirectly be linked to the LCG-map via the linktables between municipalities and territorial entities
on a higher level (for example the table “tbl_arr_gem”). Also
in this case the linktable describes a period for
which a certain relationship between municipalities and other territorial entities
was valid.
This structure makes it
possible to visualise data geographically on a map where the data, which were
valid for a particular period in time, are linked automatically to boundaries
which existed in the same particular period in time. Before the data are linked
to the LCG-map a query has to be performed, which combines only those data
records from the different tables which are valid for a particular datum.
On principle all kind of data
can be processed within this HIS/GIS-structure, as long as the data can be
linked to NIS-codes and if the datum’s for the validity of data is precisely
described.
Construction
of the database
1.
Map
of least common geometries
Starting form a vector map of the statistical neighbourhoods in 1990 all
historical boundaries, which have ever existed in
The statistical neighbourhoods have been merged, based on the first 6
digits of their NIS-identifier: This results in a map which represents more or
less the boundaries of the Belgian municipalities in 1963. The accuracy of this
map is 50m RMS, corresponding with a working scale of 1:50.000.
Each polygon of this map is described by a unique NIS-code. By
performing an overlay of this map with the historical maps (which have been
digitized by Sven Vrielinck, stored as “Mapmaker”-coverages, accuracy=+/- 250m), we pinpointed the locations
where historical boundaries existed before 1990. If the historical boundaries
were situated parallel with the boundaries of the statistical neighbourhoods,
the arcs of the map of the merged statistical neighbourhoods have been left
unmodified. If the boundaries of the (less accurate) historical maps were
located within a distance of more than 250m, the historical boundaries have
been added to the map.
In this way we created a map,
which consists of all boundaries which have ever existed in the past. These
boundaries delineate polygons. Each polygon is described by a unique
polygon-identifier, which is NOT an NIS-code.
2.
Constructyion of a relational, tempo-spatial MS-Access database
Linktable
For each polygon on the historical and recent maps the central point has
been calculated and all attribute data from the historical map have been linked
to these points. For each polygon on the LCG-map, where one of the points,
derived from the historical maps, lies within the LCG-polygons the
corresponding historical information is linked to the polygons of the LCG-map.
In this way we get information for each LCG-polygon about the corresponding
historical administrative entities. This information is stored in a table,
which consists of 2 fields:
a) The polygon-id
of the polygons from the LCG-map and
b) The NIS-code,
which is valid for a particular LCG-polygon in a certain period in time (the
period for which the original historical maps were valid).
The time-validity of a pair
a)/b) is defined in the fields “begin” en “end”:
Figure 3 Example for a linktable,
corresponding with the LCG-map in Figure
2
Data
– tables at municipality level
Each municipality which ever existed in history is described by a unique
NIS-code, which is derived from the official, statistical neighbourhood-code
(first 6 digits) plus additional digits for municipalities which have been
vanished before 1963.
The NIS-code is the key field to link data to the LCG-map. Each
data-table contains at least 3
fields:
-
NIS-code (municipality-id)
-
attribute data (any
kind of data)
-
datum (time-validity
for each pair “NIS-code/attribute data”
Queries derive the desired data from this table, which were valid for a
certain datum and link these data to the polygons, which were part of a
particular municipality at the same moment in time for which the attribute data
were valid.
Query – results for 1950 and
for 1990:
Figure 4 Simplified relational, spatial,
temporal database structure
In Figure 4 the query results (two tables right below in the
figure) for 1950 and 1990 contain identical polygon-id’s (“kaart_code”),
in combination with data (municipality names), valid for the two different
years. By linking these two tables successively to the LCG-map (via the common
polygon-id “kaart-code”), we can derive the maps of
the municipalities in 1950 and in 1990 from the LCG-map.
Construction
of an interface and possible applications
All tables are “normalised”
to avoid redundant (double) information and all tables are integrated in the
relational database structure. Based on this database an interface has been
constructed, making it possible for the (unskilled) user to derive the desired
information and to visualise this information cartographically.
The original database and the
interface are stored on CD-ROM. The user needs ArcView
3.1 and MS Access to install the database on his desktop PC. Further information
can be obtained from Eric.Vanhaute@UGent.be.
Most data and maps are also accessible via our website.
In what follows some possibilities
for the usage of the CD-ROM version are illustrated.
Example a:
Consulting data
Via an interface the user can consult data from the database. Queries,
such as “which municipalities were part of the arrondissement “Wakken” in 1820?
Answer:
example b:
Boundaries of municipalities
Figure 5 Example: Interface and cartographic
visualisation
After the user has submitted
a particular datum, a table will be generated automatically, containing the
relevant information. In ArcView this table will be
linked to the LCG-map (Figure
6 (top)) (ArcView and
MS-Access are connected via ODBC). By merging all LCG-polygons which belong to
the same territorial entity, a map is generated, representing exclusively the
boundaries which were valid at the same datum as the corresponding data (Figure 6 (bottom)).
Figure 6 Example for merged polygons, left:
municipalities in 1990, right: municipalities in 1950
Example c:
Districts and Departments
Once each LCG-polygon is
linked to data at the municipality level, valid for a particular datum,
additional data at a higher level (such as districts and departments) can be
visualised too (Figure
7).
Figure 7 Example for changing administrative
subdivisions (districts), based on the same single LCG-map
To realise this, the
following tables are involved:
-
tbl_administratieve arrondissementen
(names of districts and datum’s of existence). Each district is keyed by a unique identifier.
-
tbl_departementen en provincies
(names of departments and datum’s of existence).
Each department is keyed by a unique identifier. If the name of a department
has been changed during the last 200 years, the same identifier has been kept
but the validity of a pair: “name/id” is time-stamped in the fields “begin” and
“end”.
-
tbl_arr_gem (link between districts and
municipalities): For
each NIS-code (municipality-identifier) a time validity is defined
(“begin”/”end”), when a certain municipality/district relation was valid.
-
tbl_link_arr_prov
(link between departments and districts)
-
tbl_linktable
(link between map and municipalities).
A query determines from the linbktable, which map-polygon belongs to which
municipality. tbl_arr_gem determines the relationship
between municipalities and districts and tbl_link_arr_prov
determines the relationship between districts and departments. In this way the
boundaries at each territorial level can be visualised and the corresponding
data can be linked to this map for each moment in time.
Figure 8 Relationships between main tables at different territorial levels
From Figure 8 we can derive the information that municipality “Torhout” was part of district “Torhout”,
which was part of department “West-Vlaanderen” in
.
The user does not see the
underlying tables, he communicates with the database via a simple interface as
shown in Figure 5. All he has to do is feeding the system with
parameters.
Example d:
Calculation and visualisation of the population density and evolution
The database contains a wide spectrum of data. Population is only one variable
amongst a lot of other attributes in the fields of agriculture, industry and
socio-economics. In this example we will examine the population densities at
different datum’s in the department “
Population density 1796 Population
density 1900
Population density 1920 Population
density 1998
Figure 9 Example for the visualisation of
population evolution
From Figure 9 we can learn that population
densities declined dramatically in the western part of
In 1998 population densities seem to be more equally distributed. This
is the result of the fact that after 1980 the municipalities have become larger
entities, due to the joining operation at municipality level in the 1970s.
Staff
Prof. Eric Vanhaute (coördinator, diensthoofd afdeling Nieuwste Geschiedenis eric.vanhaute@UGent.be, http://www.flwi.ugent.be/modernhistory/ )
Torsten Wiedemann (wetenschappelijk medewerker, GIS-expert torsten_nicky@yahoo.co.uk, http://www.flwi.ugent.be/hisgis/torsten/)
Martina De Moor (wetenschappelijk medewerkster, Historica, martina.demoor@ugent.be)
Frederik De Cocker(wetenschappelijk medewerker, verantwoordelijk voor inzameling data industriële tellingen in Oost-Vlaanderen,
1846 en 1910 frederik.decocker@UGent.be)
Delphine Hajaji (wetenschappelijk medewerkster, verantwoordelijk voor inzameling data industriële tellingen in Oost-Vlaanderen,
1846 en 1910 dhajaji@UGent.be)
Frederic Lamsens (wetenschappelijk medewerker, webbeheerder, webdesign frederic.lamsens@ugent.be
Sven Thiemann (student, heeft de gegevens voor de gerechtelijke kantons ingetoetst) stinnet@imail.de