Technische Universität Wien
Orientation and Processing of Airborne Laser Scanning data
Department of Geodesy and Geoinformation - Research Groups Photogrammetry and Remote Sensing
OPALS supports reading and writing of files in the ESRI Shape format (see also here) with full attribute support using OPALS Format Definition (OFD) files. The Shape format supports different geometry types and is capable of storing attributes (for each geometry entry) in a separate DBF (dBASE) file. Whereas the OPALS Datamanager can manage geometries of different type (point, polylines and polygons) within one file, this is not possible for Shape files. OPALS will throw an exception if objects of an unmatching type are exported. This behavior can be disabled, by enabling the 'skipUnmatchingTypes' flag (see below).
Generally speaking, Shape files are often used as data exchange format for polyline or polygon objects.
For completeness it should be mentioned that shape files can be imported and exported even without OFD files based on a default strategy (import: no attributes are read. export: since the shape standard demands for a DBF file, a DBF file with one column containing an ascending id is written)
As mentioned above, a shape file can only contain geometries of one and the same type, whereas four different geometry types are supported:
Those four geometry object can be stored in three different variations
Currently, OPALS does not support measure values, limiting import and export functionality to 2d and 3d geometries (with attributes for each object).
The (export) shape OFDs may specify the shape geometry type or it is automatically determined based on the first exported geometry object. Using the corresponding xml attribute <geometryType> the following type values can be set
| value | dimension | comment |
|---|---|---|
| auto | 3d | automatic geometry type selection based on first object |
| point | 3d | each point is written as separate object (attributes for each point can be written to DBF file) |
| pointSet | 3d | points are written in chunks to the shape file (attributes only for each chunk can be stored) |
| polyline | 3d | |
| polygon | 3d | |
| point2d | 2d | |
| pointSet2d | 2d | |
| polyline2d | 2d | |
| polygon2d | 2d |
The <shape> element may also contain the <skipUnmatchingTypes> boolean attribute. Setting this flag to "true" prevents OPALS from throwing an exception, if the ODM contains geometry objects that cannot be exported to the shape file (unmatching geometry type). In this case such objects are simply ignored by the export.
Similar to the ODM, Shape files can store arbitrary attributes for each geometry entry. As mentioned above, the attributes are stored in a separate DBF file. The dBASE file format supports null values and different data types. However, one should know that numbers are always stored as text, which is why it is important to specify an appropriate width (=string length of the DBF field) for any DBF field. Floating point numbers require an additional decimals field. If an attribute exceeds the reserved field witdth, the export stops and an exception is thrown.
Although it is not recommended to export large point sets with their attributes to shape files (use efficient las/laz files instead), it
may be valuable as data exchange format for GIS and CAD software packages.
Since the Shape standard demands for a DBF file for Shape files, the default Shape export (=no OFD XML-file is specified) creates a DBF file containing one integer column (named IdCounter) containing an ascending id value for each exported entry (This predefined column can also be specified in an OFD XML-file using $IdCounter for xml attribute name).
For each DBF column an <attribute> element is required. The name of the DBF column is defined by dbfName or defaulted from name which relates to an ODM attribute or to an internal id counter (set name to $IdCount - its value is incremented for each exported object starting from zero). In general, only the XML-attribute name must always be specified, while further XML-attributes may be relevant or even mandatory - depending on the usage of predefined or user-defined ODM attributes (see here), and whether the Shape OFD is only used for import (I), or also for export (E):
| attribute | relevance | description | default |
|---|---|---|---|
| name | I/E | the OPALS attribute's name or $IdCounter | – |
| dbfName | I/E | the name of the DBF column | name |
| dbfType | E | data type in the DBF column | derived from name's data type |
| format | E | width and number of decimals of DBF column | estimated from name's data type |
As described above, appropriate width values for DBF columns are essential for the export to work. OPALS provides internal defaults for width and decimals based on the attribute type, which should be appropriate in most cases. However, it can be desirable to manually set <format> e.g. to generate more compact DBF files. To e.g. create a DBF field with a total width of 4 and only 1 decimal, set <format> to "4.1".
| ODM type | Memory Size | DBF type | width | decimals |
|---|---|---|---|---|
| int64 | 8 bytes | integer | 10 | |
| int32, uint32 | 4 bytes | integer | 10 | |
| int16, uint16 | 2 bytes | integer | 5 | |
| uint8 | 1 byte | integer | 3 | |
| int8 | 1 byte | integer | 4 | |
| bool | 1 bit | boolean | 1 | |
| float | 4 bytes | double | 9 | 5 |
| double | 8 bytes | double | 9 | 5 |
| cstr(n) | n bytes | string | n | |
| string | variable | string | 32 | |
| — | ||||
| $IdCount | integer | 6 |
In the following examples for different cases are shown
This OFD file can be used to export a point cloud with fullwave attributes for each point. It can be found in the $OPALS_ROOT/addons/formatdef/ directory. Here its application is shown.
TO COME: Polyline export based on LineModeler example
1.8.17