GRASS Vector Format
GRASS driver can read GRASS (version 6.0 and higher) vector maps.
Each GRASS vector map is represented as one datasource. A GRASS
vector map may have 0, 1 or more layers.
GRASS points are represented as wkbPoint, lines and boundaries as
wkbLineString and areas as wkbPolygon. wkbMulti* and
wkbGeometryCollection are not used. More feature types can be mixed
in one layer. If a layer contains only features of one type, it is set
appropriately and can be retrieved by OGRLayer::GetLayerDefn();
If a geometry has more categories of the same layer attached, its
represented as more features (one for each category).
Both 2D and 3D maps are supported.
Datasource name is full path to 'head' file in GRASS vector directory.
Using names of GRASS environment variables it can be expressed:
where 'mymap' is name of a vector map. For example:
Usually layer numbers are used as layer names. Layer number 0 is used
for all features without any category. It is possible to optionally
give names to GRASS layers linked to database however currently this
is not supported by grass modules. A layer name can be added in
'dbln' vector file as '/name' after layer number, for example to
1 rivers cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf
it is possible to assign name 'rivers'
1/rivers rivers cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf
the layer 1 will be listed is layer 'rivers'.
If a layer has attributes stored in a database, the query is passed to
the underlying database driver. That means, that SQL conditions which
can be used depend on the driver and database to which the layer is
linked. For example, DBF driver has currently very limited set of SQL
expressions and PostgreSQL offers very rich set of SQL expressions.
If a layer has no attributes linked and it has only categories, OGR
internal SQL engine is used to evaluate the expression. Category is
an integer number attached to geometry, it is sort of ID, but it is
not FID as more features in one layer can have the same category.
Evaluation is done once when the attribute filter is set.
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.
GISBASE is full path to the directory where GRASS is installed. By
default, GRASS driver is using the path given to gdal configure
script. A different directory can be forced by setting GISBASE
environment variable. GISBASE is used to find GRASS database drivers.
GRASS driver can read GRASS vector files if topology is available (AKA
level 2). If an error is reported, telling that the topology is not
available, it is necessary to build topology within GRASS using
If random access (GetFeature instead of GetNextFeature) is used on
layer with attributes, the reading of features can be quite slow. It
is because the driver has to query attributes by category for each
feature (to avoid using a lot of memory) and random access to database
is usually slow. This can be improved on GRASS side optimizing/writing
file based (DBF, SQLite) drivers.
Because of bug in GRASS library, it is impossible to start/stop
database drivers in FIFO order and FILO order must be used. The GRASS
driver for OGR is written with this limit in mind and drivers are
always closed if not used and if a driver remains opened kill() is
used to terminate it. It can happen however in rare cases, that the
driver will try to stop database driver which is not the last opened
and an application hangs. This can happen if sequential read
(GetNextFeature) of a layer is not finished (reading is stopped before
last available feature is reached), features from another layer are
read and then the reading of the first layer is finished, because in
that case kill() is not used.
Development of this driver was financially supported by Faunalia