EVOLUTION-MANAGER

Edit File: drv_vfk.html

<html>
<head>
<title>VFK - Czech Cadastral Exchange Data Format</title>
</head>

<h1>VFK - Czech Cadastral Exchange Data Format</h1>

This driver reads VFK files, i.e. data in the <em>Czech cadastral
exchange data format</em>. The VFK file is recognized as an datasource
with zero or more layers.

<p>
Note: starting with GDAL 1.10, the driver is compiled only if GDAL
is <em>built with SQLite support</em>.

<p>
Points are represented as wkbPoints, lines and boundaries as
wkbLineStrings and areas as wkbPolygons. wkbMulti* features are not
used. Feature types cannot be mixed in one layer.

<h3>Configuration</h3>

Starting with GDAL 1.9, the driver uses SQLite as a backend database
when reading VFK data. By default, SQLite database is created in a
directory of input VFK file (with file extension '.db'). Since GDAL
1.10, the user can define DB name with <b>OGR_VFK_DB_NAME</b>
configuration option. If <b>OGR_VFK_DB_OVERWRITE=YES</b> configuration
option is given, the driver overwrites existing SQLite database and
stores data read from input VFK file into newly created DB. Since GDAL
1.11, if <b>OGR_VFK_DB_DELETE=YES</b> configuration option is given,
the driver deletes backend SQLite database when closing the
datasource.

<p>
Starting with GDAL 1.10, resolved geometries are stored also in
backend SQLite database. It means that geometries are resolved only
once when building SQLite database from VFK data. Geometries are
stored in WKB format. Note that GDAL doesn't need to be built with
SpatiaLite support. Geometries are not stored in DB
when <b>OGR_VFK_DB_SPATIAL=NO</b> configuration option is given. In
this case geometries are resolved when reading data from DB on the
fly.

<h3>Internal working and performance tweaking</h3>

If backend SQLite database already exists then the driver reads
features directly from the database and not from input VFK file given
as an input datasource. This causes significant performance gain when
reading features by the driver.

<p>
Since GDAL 1.11, the driver reads by default all data blocks from VFK
file when building backend SQLite database. When configuration
option <b>OGR_VFK_DB_READ_ALL_BLOCKS=NO</b> is given, the driver reads
only data blocks which are requested by the user. This can be useful
when the user want to process only part of VFK data.

<h2>Datasource name</h2>

Datasource name is a full path to the VFK file.

<p>The driver supports reading files managed by VSI Virtual File
System API, which include "regular" files, as well as files in the
/vsizip/, /vsigzip/, and /vsicurl/ read-only domains.

<p>
Since GDAL 2.2 also a full path to the backend SQLite database can be
used as an datasource. By default, such datasource is read by SQLite
driver. If configuration option <b>OGR_VFK_DB_READ=YES</b> is given,
such datasource is open by VFK driver instead.
  
<h2>Layer names</h2>

VFK data blocks are used as layer names.

<h2>Filters</h2>

<h3>Attribute filter</h3>

An internal SQL engine is used to evaluate the expression. Evaluation
is done once when the attribute filter is set.

<h3>Spatial filter</h3>

Bounding boxes of features stored in topology structure are used to
evaluate if a features matches current spatial filter. Evaluation is
done once when the spatial filter is set.

<h2>References</h2>

<ul>
<li> <a href="http://geo.fsv.cvut.cz/~landa/publications/2010/gis-ostrava-2010/paper/landa-ogr-vfk.pdf">OGR
VFK Driver Implementation Issues</a></li>
<li> <a href="http://freegis.fsv.cvut.cz/gwiki/VFK">Open Source Tools for VFK format</a> (in Czech)</li>
<li> <a href="http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=0&AKCE=DOC:10-VF_ISKNTEXT">Czech
cadastral exchange data format documentation</a> (in Czech)</li>
</ul>

</body>
</html>