Gdalwrite.vect

Gdalwrite.vect is the part of GDAL, used to write vector data and non-spatial data.

Gdalwrite.vect is available since version 7.408.

We test and support (options for) the following formats:

• csv
• dbf
• ESRI Shapefile
• geopackage

a layer is written complete

Since GeoDMS 20.17.0 a vector layer is written with all its storable attribute, also when only one of them is requested. Before 20.17.0, requesting a single attribute of a gdalwrite.vect container wrote the other columns of the same layer as <null> columns (and left features without their geometry); now the other columns are calculated and written along, so the file is complete regardless of which column triggered the write. An attribute that fails to calculate takes no part in the write and gets no field, rather than blocking the file.

Versions 20.17.0 up to and including 20.19.0 raise the error "Cannot start ChangeInterest while doing ChangeInterest; check for recursive dependencies" when one written attribute of a layer refers to another written attribute of the same layer, for example:

container Export : StorageName = "='%LocalDataDir%/result.csv'", StorageType = "gdalwrite.vect"
{
	unit<uint8> sel := select_with_org_rel(condition)
	{
		attribute<string> name          := org_rel->name;
		attribute<string> RekenstapNaam := name;  // refers to a sibling column: error in 20.17.0 .. 20.19.0
	}
}

Since GeoDMS 20.19.1 this works again: the companion columns are brought into play when the layer is actually written, instead of when a column comes under interest. On the affected versions, the workaround is to let both attributes refer to the source directly (RekenstapNaam := org_rel->name;) instead of to the sibling column.

Since GeoDMS 20.19.0 a written column carries the engine's canonical spelling of its attribute name, which for a name that case-folds onto one of the engine's own names (value, attr, unit, item, param, nrofrows, a value type) is lower case: an attribute configured as Value produces a column named value. See case sensitivity for the rule, the measured before/after, and what it means for consumers that read a column by its exact name.

the geometry column may have any name

Since GeoDMS 20.19.2 the column that carries a layer's geometry is recognized by its composition — polygon, arc or a point — and no longer by being called geometry. A geometry under another name, say region (polygon), now gives its layer that geometry type and its features their shape.

Since GeoDMS 20.23.1 a column with composition multipoint is a geometry as well, written as a MultiPoint per feature. Before, it was not recognized as one: the write was refused as if the column were a field of a type the driver cannot store, whatever its name.

Before 20.19.2 it did not. The layer was created without a geometry field, so its features had no shape and, for a shapefile, only the .dbf appeared next to the configured .shp — without an error. 20.19.1 turned that silence into a refusal:

GDAL Error: driver ESRI Shapefile does not support writing of values type fpoint

because the column was measured against the driver's creation field types, and no OGR field type corresponds to fpoint, dpoint or spoint. A geometry is not a field: the driver writes it as coordinates, so its field types say nothing about it, and a shapefile stores those coordinates as doubles whichever point value type the model uses.

So a layer written as a whole fails outright on 20.19.1 and writes shapeless features on every earlier version, while a geometry attribute carrying its own StorageName was refused the same way on 20.19.0 too. Naming the column geometry avoids all of that and is what the examples on this wiki do; from 20.19.2 the name is free.

That last case, a geometry attribute with its own .shp StorageName next to a .dbf on the domain unit, is not a gdalwrite.vect configuration at all unless you say so: it needs StorageType = "shp", the ESRI Shapefile storage manager, which writes the one attribute it is configured on and leaves the .dbf to the domain unit. Writing it with gdalwrite.vect instead makes GDAL create a whole layer, .dbf included, on top of the .dbf the domain unit writes.

polygon rings are closed on write

Since GeoDMS 20.19.2 every ring of a polygon is written closed: where the value does not repeat a ring's first point at the end, gdalwrite.vect appends it before handing the ring to GDAL. Closure is what the ESRI Shapefile specification and OGC simple features require, and GDAL does not add the point for us.

Before 20.19.2 the ring went out as held, so a single-ring polygon that the model left open produced a file that gdal.vect refuses to read back, with Check Failed Error: ring->getY(0) == ring->getY(numPoints-1). See ESRI Shapefile for the message in full, for why only single-ring values can be affected, and for what to do with a file an older version wrote.

a layer is written in one transaction

Since GeoDMS 20.23.1 a layer is written in one transaction where the driver has them, such as GeoPackage, PostGIS and SQLite: when writing fails, none of the layer is kept. Before, a transaction was committed per tile, also when writing failed, so a failed export left part of a layer, which the next run then updated in place. A layer written to a .gdb (OpenFileGDB, which emulates a transaction by backing up the layer's files) is backed up once instead of once per tile. A driver without transactions, such as ESRI Shapefile or CSV, writes every feature directly, as before.

see also

• gdal.vect
• gdalwrite.grid
• tree item name - case folding of written column names