GRASS GIS: Importing and processing of cadastral data in Czech cadastral exchange data format

Martin Landa
Czech Technical University in Prague
Faculty of Civil Engineering, Department of Mapping and Cartography
Thákurova 7, 166 29 Prague 6 - Dejvice

E-mail: martin.landa@fsv.cvut.cz

Abstract

GIS data sources are various and reflect a given specialization of geographic information system. The most frequent input GIS data are cadastral data, building services, ZABAGED (Fundamental Base of Geographic Data) data or orthophotomaps. GRASS GIS as a piece of Free Software (GNU GPL license) supports a huge range of external data formats especially in connection with implemented GDAL/OGR library. Nevertheless, support of specific Czech data formats is practically missing. A GRASS module which was created in the frame of the author's diploma thesis is trying to change this situation at least in connection with Czech cadastral exchange data format.

This GRASS module (v.in.vfk) allows user to create a GRASS vector map based on data in Czech cadastral exchange data format. It means that vector geometry is stored in GRASS native vector format (GRASS GIS 6.x) and attribute data is held in a corresponding number of database tables linked to a vector map. This enables user to import this kind of data into GRASS without major problems and then to process or analyse it. As a result, it is not necessary to use any external programs for data conversion into chosen data format supported by GRASS (e.g. ESRI ShapeFile). However, it should be stressed that GRASS does not contain any special tools for cadastral data processing. On the other side, it does not mean that GRASS users cannot work with this kind of data.

Background

Czech land register information system contains geographical data and official maps as well as survey data, property attributes, and fund documentation. ISKN ("Informační Systém Katastru Nemovitostí") is cadastral information system covering the structures and principles of land databases. ISKN data is a combination of alphanumeric (SPI) and graphical (SGI) data. SPI data includes information about parcels, people, buildings, and contracts for 100 percent of the republic. SGI data includes detailed land maps, available only for about 25 percent of the country.

Cadastral data can be distributed in ISKN exchange data format (VFK). There are two types of this format. The old format (SVF) used before ISKN implementation (official support of this format was stopped in 2004). And the new exchange data format (NVF) which was naturally influenced by ISKN implementation in 2001. The GRASS module, which is described in this paper, works only with the new cadastral exchange data format (NVF - VFK files).

ISKN exchange data format (VFK) is ASCII format (ČSN ISO 8859-2 or WIN1250 encoding) which includes both kind of data - alphanumeric (SPI) and graphical (SGI) data. VFK files contain required data units (blocks) selection (see table 1).

ISKN exchange data format - VFK

The structure of the format is closely described in documentation listed in "References". Here we present only the basics of the format structure needed for understanding GRASS module v.in.vfk concept.

VFK file may contain four fundamental parts:

• header (&H)
• data units - blocks (&B)
• data records (&D)
• end of data (&K)

The following example of a VFK file contains one data unit - &BSOBR and three data records of the unit - &DSOBR:

&HVERZE;"2.8"
&HVYTVORENO;"13.10.2004 09:02:56"
&HCODEPAGE;"WE8ISO8859P2"
&BSOBR;ID N30;STAV_DAT N2;KATUZE_KOD N6;CISLO_ZPMZ N5;CISLO_TL N4;
CISLO_BODU N12;UPLNE_CISLO N12;SOURADNICE_Y N10.2;SOURADNICE_X N10.2;KODCHB_KOD N2
&DSOBR;311040708;0;654299;1427;;1;1014270001;650451.45;1069791.42;4
&DSOBR;311041708;0;654299;1427;;3;1014270003;650436.18;1069799.13;4
&DSOBR;311042708;0;654299;1427;;5;1014270005;650433.41;1069787.66;4
&K

For list of available data units (blocks) see table 1.

History and motivation

Cadastral data is one of the most frequent input data for various GIS. GRASS GIS allows user to import data in many data formats (especially via GDAL/OGR library). This library supports many well-known raster and vector formats. On the other side, local data formats (including ISKN exchange data format) are not supported by GDAL/OGR library.

GRASS GIS is the famous and widely used Free Software/Open-Source GIS, used for data management, image processing, graphics production, spatial modelling and visualization of many types of data. It is released under GNU General Public License (GPL). GRASS is a powerful utility with a wide range of applications in many different areas of scientific research. GRASS is currently used in academic and commercial settings around the world, as well as many governmental agencies including NASA, NOAA, the National Park Service and many environmental consulting companies. Wide range of tools (in GRASS terminology "modules") which GRASS offers and relatively huge number of GRASS users were the main reasons why GRASS was chosen as a background in the thesis.

The GRASS module v.in.vfk was created in the frame of diploma thesis "Implementation of a GRASS module for importing data in Czech cadastral exchange data format". The main goal of this work has been to allow user to import cadastral data in specific Czech cadastral exchange data format (VFK) into GRASS GIS.

The GRASS module v.in.vfk

The GRASS module v.in.vfk is written in C programming language (almost the whole source code of GRASS is in C programming language). The current version of the module has been released as a result of the diploma thesis. The source code of this program is a little bit "nasty", so many improvements must be done in the future. Complete rewriting of the module v.in.vfk is planned...

GRASS module v.in.vfk creates a new vector map layer in GRASS database (in native GRASS 6 vector format). Because of many improvements of the native vector format and vector architecture in GRASS 6 which have been done, the module works correctly only in GRASS 6.x. GRASS 5.x (or 4.x) cannot be used (due to its old vector architecture). Created output vector map layer covers vector geometry (stored in GRASS database structure) and a set of corresponding attribute tables (only PostgreSQL database tables supported). In the future also MySQL database tables and SQLite tables should be supported. The default GRASS database driver "dbf" cannot be used in connection with this module.

Output vector map layer contains number of thematic layers (see table 3). For further data processing, it is necessary to split these thematic layers into a corresponding number of GRASS vector map layers. A map produced by module v.vfk.vfk (parameter output) is not topologically correct - contains many duplicate lines, boundaries, centroids or areas without centroids, etc. A user has the possibility to use the special script called v.vfk.extract which extracts required thematic layer from the map and creates a new vector map layer in the GRASS database. This conception will be changed as soon as possible - GRASS module v.in.vfk should create specified thematic vector map layers as well.

The GRASS module v.in.vfk is a standard GRASS program, for Tcl/Tk GUI (graphical user interface) of the module see figure 1.

Figure 1: GRASS module v.in.vfk - Tcl/Tk GUI

Naturally, user is able to run the module from the GRASS command prompt. Parameter help prints a short module description and its syntax.

 GRASS > v.in.vfk help

Description:
 Import VFK file (ISKN) into a GRASS vector map.

Usage:
 v.in.vfk [-ernduf] [input=name] output=name [type=name[,name,...]]

Flags:
  -e   Extend location extents based on input data
  -r   Drop all redundant tables
  -n   Null category (-1)
  -d   Data type timestamp instead of varchar
  -u   Create unique constraints
  -f   Create primary key and foreign key constraints

Parameters:
   input   VFK file to be imported, if not given reads from standard input
  output   Name of output vector
    type   Type
           options: point,line,boundary,centroid,area
           default: point,line,boundary,centroid,area

As can be seen, only parameter output is required. The other parameters are optional. We should stress that the parameter input - input file (containing data in Czech cadastral exchange data format) can be set by parameter input or read from standard input. Both possibilities are shown bellow:

 GRASS > v.in.vfk input=Exportvse.vfk output=bylany

 GRASS > v.in.vfk output=bylany < Exportvse.vfk

In this case, the new vector map layer ("bylany") in GRASS database is created. For more information about importing of cadastral data in VFK format, see the next section ("Importing, processing and analyzing of cadastral data in GRASS GIS").

By the way, manual pages of the module are available by the following GRASS command:

 GRASS > g.manual v.in.vfk

Module conception

The process of importing of cadastral data can be divided into two different parts:

1. creating database tables and inserting records into the tables,
2. creating and building vector geometry and topology.

At first, an empty vector map layer is created and its metadata is written into the head file.

Database tables and inserting of data records

First of all, the input data is loaded. Each line starts with the special tag:

• &H - metadata, saved in head file and in special database table "hlavicka",
• &B - data unit (block), rules for creating the database table (number of columns, column names, column data types),
• &D - data records, to insert into the specified database table.

After submission of the input data, all defined database tables are created and data records are inserted into the tables. Metadata is written (head file), too. Database tables are linked to the output vector map layer by a fixed layer number (see table 1 and figure 2). Some of these tables contain data records which will be used for creating the vector geometry.

The fixed (or predefined) layer number has four digits:

   is ib

where:

      is ... data unit group identifier (see table 1)

      ib ... data unit identifier in selected group (see table 1)

For example, data unit SOBR (i.e. table "souradnice_obrazu") is part of the data unit group PKMP (is = 16). Data unit SOBR is the first data unit (ib = 01) in this data unit group. As a result, database table "souradnice_obrazu" will be linked to the vector map layer by layer number "1601".

Table 1: List of data units, predefined table names and layer numbers

Note: * ... centralized dial.

Figure 2: Database tables schema

At the end of this phase, input data is loaded, data tables created and data records inserted into the tables - everything is prepared for vector geometry building.

Creating the vector geometry

According to the description of VFK format, some data units (i.e. database tables) contain geographically orientated data records (points, lines, boundaries or polygons). The content of an output vector map layer directly depends on these tables (see table 2). By the way, using parameter type, it is possible to influence vector geometry elements.

Table 2: Database tables containing geographic data

At first, the module checks if these tables exist. When one of them is found, function create_points () or create_lines () is executed. The functions write vector elements (points, lines, boundaries or centroids) to the output vector map layer.

Attribute tables

During this phase (inside the functions mentioned above), the attribute tables structure is built, too (see figure 1). The tables (i.e. attribute tables) are linked to the output vector map layer by a layer number, starting at 1. Each vector element has a unique identifier (category number) which connects the geometry element with its attributes (data record(s) stored in attribute table). Assessment of the attributes is unique:

[layer number] + [category] = [database] + [database driver]

As a result, more then one hundred attribute tables can be linked to the output vector map layer (e.g. testing file available at ČÚZK websites - 122 attribute tables). Of course, some of them are linked to the map layer several times. See figure 3 for tables relation diagram starting from database table "souradnice_obrazu".

Figure 3: Tables relation diagram - attribute tables structure (from table "souradnice_obrazu")

In this example, the following tables will be linked to the output vector map layer "bylany" (see GRASS module v.db.connect):

  1 bylany_souradnice_obrazu cat iskn pg
  2 bylany_zpmz cat iskn pg
  3 bylany_katastr_uzemi cat iskn pg
  4 bylany_obce cat iskn pg
  5 bylany_okresy cat iskn pg
  6 bylany_kraje cat iskn pg
  7 bylany_t_sourad_sys cat iskn pg
  9 bylany_kody_char_q_bodu cat iskn pg

where:

   [layer number] [output_table name] [category column] [database] [database driver]

Vector geometry elements which will be written to the output vector map layer is possible to regulate by parameter type:

• point - the output vector map layer contains only points
• line - only lines
• boundary - only boundaries
• centroid - only centroids
• area - only boundary + centroid

Default combination is "point,line,boundary,centroid" - all (2D) vector types. The user can also create an empty output vector map layer only with linked attribute tables (type=).

During this phase, all required vector elements are written to the output vector map layer. Layers report (number of elements, minimal and maximal category number) prints GRASS module v.category, for example:

  LAYER/TABLE 1/bylany_souradnice_obrazu:
  type       count        min        max
  point       6114          1       6114
  line           0          0          0
  boundary       0          0          0
  centroid       0          0          0
  area           0          0          0
  all         6114          1       6114
  LAYER/TABLE 2/bylany_zpmz:
  type       count        min        max
  point       5881          1         80
  ...
  LAYER/TABLE 3/bylany_katastr_uzemi:
  type       count        min        max
  point       5881          1          1
  ...
  LAYER/TABLE 4/bylany_obce:
  type       count        min        max
  point       5881          1          1
  ...
  LAYER/TABLE 5/bylany_okresy:
  type       count        min        max
  point       5881          1          1
  ...
  LAYER/TABLE 6/bylany_kraje:
  type       count        min        max
  point       5881          1          1
  ...
  LAYER/TABLE 7/bylany_t_sourad_sys:
  type       count        min        max
  point       5881          1          1
  ...
  LAYER/TABLE 8/bylany_kody_char_q_bodu:
  type       count        min        max
  point       6114          2          8
  ...

Conclusive operations

First, all redundant layer numbers (connection between vector map layer and database table) are deleted (e.g. attribute table "souradnice_obrazu" is linked to the map by layer number "1601" and "1" as well - that means that dblink "1601" can be deleted from dblink file). Note that no database tables are dropped, only dblinks (layer numbers) deleted (see function clean_dblinks ()). In addition, all redundant database tables (i.e. tables which are not linked to the map as attribute tables) can be dropped by the flag -r.

After that, the vector topology is built and topology building report is printed on the standard output:

  Building topology ...
  15870 primitives registered      
  Building areas:  100%
  894 areas built      
  16 isles built
  Attaching islands:  100%
  Attaching centroids:  100%
  Topology was built.
  Number of nodes     :   7347
  Number of primitives:   15870
  Number of points    :   6146
  Number of lines     :   78
  Number of boundaries:   8445
  Number of centroids :   1201
  Number of areas     :   894
  Number of isles     :   16
  Number of incorrect boundaries   :   4174
  Number of centroids outside area :   373
  Number of duplicate centroids    :   106
  Number of areas without centroid :   172

As can be seen from this report, the output vector map layer contains many incorrect boundaries, duplicate centroids or areas without centroid. For further data processing, this map must be split into several thematic map layers (i.e. GRASS vector map layer). This process is described in the next section ("Importing, processing and analyzing of cadastral data in GRASS GIS").

Importing, processing and analyzing of cadastral data in GRASS GIS

In the previous section, the GRASS module v.in.vfk was slightly described. Here we demonstrate how to import data in VFK format into GRASS location.

First, we choose appropriate GRASS location and mapset (or we can create a new one). Coordinate system of this location must be S-JTSK. Creating a GRASS location with S-JTSK coordinate system is closely explained in the thesis ("Implementation of a GRASS module for importing data in Czech cadastral exchange data format", chapter 6.1). We also have to set required connection to the database (see GRASS module db.connect). As we know, only PostgreSQL database system is supported. For example, we set up the connection to PostgreSQL database "iskn" (we have already installed this database system and set up the access permissions):

 GRASS > db.connect driver=pg database=iskn

Now, we are able to start the import of VFK data into chosen GRASS location/mapset. There is a simple example - input file (in VFK format) is "Exportvse.vfk", name of the output vector map layer in GRASS database is "bylany" and all vector types will be imported:

 GRASS > v.in.vfk in=Exportvse.vfk out=bylany

 GRASS > v.in.vfk out=bylany < Exportvse.vfk

Besides the parameter type, number of flags are available:

• -e - extend location extents based on the input data,
• -r - drop all redundant tables,
• -n - null category (-1),
• -d - data type timestamp instead of varchar,
• -u - create unique constraints,
• -f - create primary key and foreign key constraints.

After successful data import, we can print out a list of connected tables by GRASS module v.db.connect:

 GRASS > v.db.connect bylany -g

999 bylany_hlavicka cat iskn pg
1007 bylany_zdroje_parcel_ze cat iskn pg
...
1803 bylany_nz_zpmz cat iskn pg
1 bylany_souradnice_obrazu cat iskn pg
2 bylany_zpmz cat iskn pg
...
8 bylany_kody_char_q_bodu cat iskn pg
10 bylany_spojeni_b_poloh cat iskn pg
11 bylany_souradnice_obrazu cat iskn pg
...
18 bylany_kody_char_q_bodu cat iskn pg
20 bylany_hranice_parcel cat iskn pg
21 bylany_parcely cat iskn pg
...
32 bylany_zp_vyuziti_bud cat iskn pg
34 bylany_obrazy_budov cat iskn pg
35 bylany_t_prvku_p_dat cat iskn pg
...
42 bylany_telesa cat iskn pg
44 bylany_dalsi_prvky_mapy cat iskn pg
45 bylany_t_prvku_p_dat cat iskn pg
47 bylany_spojeni_b_mapy cat iskn pg
49 bylany_obrazy_parcel cat iskn pg
50 bylany_t_prvku_p_dat cat iskn pg
...
76 bylany_predmety_rizeni cat iskn pg
78 bylany_obrazy_budov cat iskn pg
79 bylany_t_prvku_p_dat cat iskn pg
...
98 bylany_predmety_rizeni cat iskn pg
100 bylany_obrazy_bodu_bp cat iskn pg
101 bylany_souradnice_obrazu cat iskn pg
...
108 bylany_kody_char_q_bodu cat iskn pg
110 bylany_oznaceni_bpej cat iskn pg
112 bylany_souradnice_polohy cat iskn pg

The first table - "bylany_hlavicka" (i.e. layer number 999) contains the metadata of the map (tag &H). In addition, many redundant tables are still linked to the map (layer numbers 1007 - 1803). These tables contain data records which have no connection with vector elements in the output map (or tables with no data records). Then it is possible to see the attribute tables (connection with vector geometry via category number) - layer numbers from 1 to 112. Using the flag -r, all redundant tables can be dropped (not only dblinks, but the data is deleted too!).

For better orientation, layer number between each thematic layer is skipped, see table 3.

Table 3: List of thematic layers in the output map layer "bylany"

Script v.vfk.extract

This simple script allows a user to split a map layer created by module v.in.vfk into several vector map layers which contain only one - required thematic layer. As a result, vector topology of produced map layers should be correct. The script is available only in Czech language. There is a short description of the module (script):

 GRASS > v.vfk.extract help

Popis:
 Extrahování jednotlivých tematických vrstev katastrální mapy.

Použití:
 v.vfk.extract [-tnc] mapa=name [volba=name]

Přepínače:
  -t   nekopírovat atributové tabulky
  -n   kopírovat atributové tabulky pomocí modulu v.extract
  -c   vyčistit výstupní vektorovou mapu (vhodné pro obrazy budov)

Parametry:
   mapa   vektorová mapa
  volba   tematická vrstva (body polohopisu, obrazy parcel, obrazy budov, další prvky mapy, BPEJ)
          volby:bp,op,ob,dpm,bpej
          výchozí: op

Note: The script requires patched GRASS module v.extract (the patch is part of v.in.vfk distribution)!

We can extract at most five thematic layers (default is "op"):

• bp - points of situation (basic tables: "souradnice_obrazu", "obrazy_bodu_bp" and "souradnice_polohy"),
• op - parcels (basic tables: "hranice_parcel" and "obrazy_parcel"),
• ob - buildings (basic table: "obrazy_budov"),
• dpm - other map elements (basic table: "dalsi_prvky_mapy"),
• bpej - BPEJ - estimated pedologic-ecological unit (basic tables: "hranice_bpej" and "oznaceni_bpej").

The name of extracted vector map layer is derived from the name of input map layer and selected thematic map layer, e.g. "bylany_op":

 GRASS > v.vfk.extract bylany volba=op

This map layer should not contain any incorrect elements, see report from v.build.

 GRASS > v.build bylany_op

Building topology ...
7044 primitives registered      
Building areas:  100%
1007 areas built      
55 isles built
Attaching islands:  100%
Attaching centroids:  100%
Topology was built.
Number of nodes     :   6092
Number of primitives:   7044
Number of points    :   0
Number of lines     :   0
Number of boundaries:   6037
Number of centroids :   1007
Number of areas     :   1007
Number of isles     :   55

List of linked attribute tables prints well-known GRASS module v.db.connect:

 GRASS > v.db.connect bylany_op -g

20 bylany_op_hranice_parcel cat bylany pg
...
32 bylany_op_zp_vyuziti_bud cat bylany pg
49 bylany_op_obrazy_parcel cat bylany pg
...
76 bylany_op_predmety_rizeni cat bylany pg

See figure 4 below for example of four fundamental thematic layers (points of situation, parcels, buildings and other map elements).

Figure 4: Composition of four fundamental thematic layer created by v.vfk.extract

Map outputs

In this section we take a look at a hardcopy output maps produced by GRASS module ps.map. GRASS does not offer any special map symbols for cadastral maps. The library of map symbols for cadastral maps "dkm" (only for points and centroids) has been designed in the frame of the diploma thesis and is distributed with the module v.in.vfk. There is a short example of the map symbol "garden":

VERSION 1.0
BOX -1 -1 1 1
POLYGON
  RING
    FCOLOR NONE	
    ARC 0 0.75 0.75 360 0 C
  END
END
STRING
  LINE
     0    0
     1.75 0
  END
END

Figure 6: Map symbol "garden" (dimensions in mm)

The map symbols (see figure 6) can be used with GRASS modules d.vect (to display vector data in GRASS monitor) and ps.map (to create hardcopy PostScript map output).

See figures 7 and 8 for hardcopy map output examples produced by GRASS module ps.map.

Figure 7: Hardcopy map output created by ps.map

Figure 8: Hardcopy map output produced by ps.map - land types

Examples of basic analysis

Figure 9: Land use graph (produced by R)

Figure 10: Parcels selection (100 meters from standpoint)

The future

The development of the module v.in.vfk has started in February 2005. The first version of the module (0.1) was released in June 2005 as a part of the diploma thesis. Many problems (e.g. missing support of data type "bigint" in database driver for PostgreSQL) have appeared and kept pending.

The GRASS module

The next generation of this module (i.e. set of tools for import of the VFK files into GRASS) requires complete rewriting of the base program (C/C++ programming language). Probably the most serious problem is missing support of the data type "bigint" in database driver for PostgreSQL database system.

An output map layer produced by v.in.vfk contains number of thematic layers. This map must be split into more map layers by another module v.vfk.extract. The module v.vfk.extract functionality will be included in the next version of the module v.in.vfk. Therefore no extra tools (like v.vfk.extract) are needed any more.

QGIS plugin

It looks like that QGIS is going to be used as a sophisticated GUI (graphical user interface) for GRASS. GRASS is command-line orientated piece of software, having its own relatively simple GUI based on Tcl/Tk library. QGIS contains GRASS plugin which allows to load GRASS raster and vector map layers, edit GRASS vector map layers or run selected GRASS modules directly from QGIS environment.

Planned QGIS plugin should allow a user to visualize cadastral maps or to put more sophisticated map queries, etc.

Conclusion

GRASS users can import cadastral data in Czech cadastral exchange data format (VFK files) into GRASS GIS by using module v.in.vfk without any fundamental problems. As a result, there is no need to use any external programs for (mostly losing) data conversion into chosen data format supported by GRASS.

By the way, GRASS does not offer any special tools for further data processing of cadastral data (maps). It will be part of further development (after improvement of the import module v.in.vfk). It means implementation of a special set of GRASS modules and development of QGIS plugin.

References

1. The GRASS module v.in.vfk (only in Czech)
2. Martin Landa: Diploma thesis Implementation of a GRASS module for importing data in Czech cadastral exchange data format (only in Czech)
3. Structure of Czech cadastral exchange data format
4. Official websites GIS GRASS and GRASS GIS Czech user group
5. Markus Neteler and Helena Mitášová: Open source GIS: A GRASS GIS Approach, Kluwer Academic Publishers Group, 2002, ISBN 1-4020-7088-8
6. Marcus Neteler: GRASS Handbuch (Czech translation), 2003
7. Otto Dassau, Stephan Holl, Marcus Neteler and Manfred Redslob: GRASS GIS 6.0 Kursskript (Czech translation), 2005
8. Radim Blažek, Marcus Neteler and Roberto Micarelli: The new GRASS 5.1 vector architecture - GRASS users conference 2002
9. Martin Landa: GIS GRASS as an aid in GIS and remote sensing instruction - GIS Ostrava 05 conference
10. Quantum GIS website
11. GDAL - Geospatial Data Abstraction Library, OGR - Simple Features Library
12. Free Software Foundation and GNU General Public License
13. Tcl programming language and Tk graphical user interface toolkit
14. The R Project for Statistical Computing