|
GDAL
|
This document is intended to document using the OGR C++ classes to read and write data from a file. It is strongly advised that the read first review the OGR Architecture document describing the key classes and their roles in OGR.
It also includes code snippets for the corresponding functions in C and Python.
For purposes of demonstrating reading with OGR, we will construct a small utility for dumping point layers from an OGR data source to stdout in comma-delimited format.
Initially it is necessary to register all the format drivers that are desired. This is normally accomplished by calling GDALAllRegister() which registers all format drivers built into GDAL/OGR.
In C++ :
In C :
Next we need to open the input OGR datasource. Datasources can be files, RDBMSes, directories full of files, or even remote web services depending on the driver being used. However, the datasource name is always a single string. In this case we are hardcoded to open a particular shapefile. The second argument (GDAL_OF_VECTOR) tells the OGROpen() method that we want a vector driver to be use and that don't require update access. On failure NULL is returned, and we report an error.
In C++ :
In C :
A GDALDataset can potentially have many layers associated with it. The number of layers available can be queried with GDALDataset::GetLayerCount() and individual layers fetched by index using GDALDataset::GetLayer(). However, we will just fetch the layer by name.
In C++ :
In C :
Now we want to start reading features from the layer. Before we start we could assign an attribute or spatial filter to the layer to restrict the set of feature we get back, but for now we are interested in getting all features.
With GDAL 2.3 and C++11:
With GDAL 2.3 and C:
If using older GDAL versions, while it isn't strictly necessary in this circumstance since we are starting fresh with the layer, it is often wise to call OGRLayer::ResetReading() to ensure we are starting at the beginning of the layer. We iterate through all the features in the layer using OGRLayer::GetNextFeature(). It will return NULL when we run out of features.
With GDAL < 2.3 and C++ :
With GDAL < 2.3 and C :
In order to dump all the attribute fields of the feature, it is helpful to get the OGRFeatureDefn. This is an object, associated with the layer, containing the definitions of all the fields. We loop over all the fields, and fetch and report the attributes based on their type.
With GDAL 2.3 and C++11:
With GDAL < 2.3 and C++ :
In C :
There are a few more field types than those explicitly handled above, but a reasonable representation of them can be fetched with the OGRFeature::GetFieldAsString() method. In fact we could shorten the above by using OGRFeature::GetFieldAsString() for all the types.
Next we want to extract the geometry from the feature, and write out the point geometry x and y. Geometries are returned as a generic OGRGeometry pointer. We then determine the specific geometry type, and if it is a point, we cast it to point and operate on it. If it is something else we write placeholders.
In C++ :
In C :
The wkbFlatten() macro is used above to convert the type for a wkbPoint25D (a point with a z coordinate) into the base 2D geometry type code (wkbPoint). For each 2D geometry type there is a corresponding 2.5D type code. The 2D and 2.5D geometry cases are handled by the same C++ class, so our code will handle 2D or 3D cases properly.
Starting with OGR 1.11, several geometry fields can be associated to a feature.
In C++ :
In C :
In Python:
Note that OGRFeature::GetGeometryRef() and OGRFeature::GetGeomFieldRef() return a pointer to the internal geometry owned by the OGRFeature. There we don't actually deleted the return geometry.
With GDAL 2.3 and C++11, the looping over features is simply terminated by a closing curly bracket.
With GDAL 2.3 and C, the looping over features is simply terminated by the following.
For GDAL < 2.3, as the OGRLayer::GetNextFeature() method returns a copy of the feature that is now owned by us. So at the end of use we must free the feature. We could just "delete" it, but this can cause problems in windows builds where the GDAL DLL has a different "heap" from the main program. To be on the safe side we use a GDAL function to delete the feature.
In C++ :
In C :
The OGRLayer returned by GDALDataset::GetLayerByName() is also a reference to an internal layer owned by the GDALDataset so we don't need to delete it. But we do need to delete the datasource in order to close the input file. Once again we do this with a custom delete method to avoid special win32 heap issues.
In C/C++ :
All together our program looks like this.
With GDAL 2.3 and C++11 :
In C++ :
In C :
In Python:
As an example of writing through OGR, we will do roughly the opposite of the above. A short program that reads comma separated values from input text will be written to a point shapefile via OGR.
As usual, we start by registering all the drivers, and then fetch the Shapefile driver as we will need it to create our output file.
In C++ :
In C :
Next we create the datasource. The ESRI Shapefile driver allows us to create a directory full of shapefiles, or a single shapefile as a datasource. In this case we will explicitly create a single file by including the extension in the name. Other drivers behave differently. The second, third, fourth and fifth argument are related to raster dimensions (in case the driver has raster capabilities). The last argument to the call is a list of option values, but we will just be using defaults in this case. Details of the options supported are also format specific.
In C ++ :
In C :
Now we create the output layer. In this case since the datasource is a single file, we can only have one layer. We pass wkbPoint to specify the type of geometry supported by this layer. In this case we aren't passing any coordinate system information or other special layer creation options.
In C++ :
In C :
Now that the layer exists, we need to create any attribute fields that should appear on the layer. Fields must be added to the layer before any features are written. To create a field we initialize an OGRField object with the information about the field. In the case of Shapefiles, the field width and precision is significant in the creation of the output .dbf file, so we set it specifically, though generally the defaults are OK. For this example we will just have one attribute, a name string associated with the x,y point.
Note that the template OGRField we pass to CreateField() is copied internally. We retain ownership of the object.
In C++:
In C:
The following snipping loops reading lines of the form "x,y,name" from stdin, and parsing them.
In C++ and in C :
To write a feature to disk, we must create a local OGRFeature, set attributes and attach geometry before trying to write it to the layer. It is imperative that this feature be instantiated from the OGRFeatureDefn associated with the layer it will be written to.
In C++ :
In C :
We create a local geometry object, and assign its copy (indirectly) to the feature. The OGRFeature::SetGeometryDirectly() differs from OGRFeature::SetGeometry() in that the direct method gives ownership of the geometry to the feature. This is generally more efficient as it avoids an extra deep object copy of the geometry.
In C++ :
In C :
Now we create a feature in the file. The OGRLayer::CreateFeature() does not take ownership of our feature so we clean it up when done with it.
In C++ :
In C :
Finally we need to close down the datasource in order to ensure headers are written out in an orderly way and all resources are recovered.
In C/C++ :
The same program all in one block looks like this:
In C++ :
In C :
In Python :
Starting with OGR 1.11, several geometry fields can be associated to a feature. This capability is just available for a few file formats, such as PostGIS.
To create such datasources, geometry fields must be first created. Spatial reference system objects can be associated to each geometry field.
In C++ :
In C :
To write a feature to disk, we must create a local OGRFeature, set attributes and attach geometries before trying to write it to the layer. It is imperative that this feature be instantiated from the OGRFeatureDefn associated with the layer it will be written to.
In C++ :
In C :
In Python :
1.8.13.