[Git][debian-gis-team/gdal-grass][upstream] New upstream version 1.0.1
Bas Couwenberg (@sebastic)
gitlab at salsa.debian.org
Tue Jun 14 14:22:28 BST 2022
Bas Couwenberg pushed to branch upstream at Debian GIS Project / gdal-grass
Commits:
a062b4b7 by Bas Couwenberg at 2022-06-14T15:07:01+02:00
New upstream version 1.0.1
- - - - -
10 changed files:
- Makefile.in
- − README
- + README.md
- aclocal.m4
- + docs/grass_raster.md
- + docs/grass_raster.rst
- + docs/grass_vector.md
- + docs/grass_vector.rst
- grass.cpp
- ogrgrassdriver.cpp
Changes:
=====================================
Makefile.in
=====================================
@@ -22,9 +22,9 @@ OLIBNAME = ogr_GRASS.so
default: $(GLIBNAME) $(OLIBNAME)
install: default
- install -d $(AUTOLOAD_DIR)
- cp $(GLIBNAME) $(AUTOLOAD_DIR)
- cp $(OLIBNAME) $(AUTOLOAD_DIR)
+ install -d $(DESTDIR)$(AUTOLOAD_DIR)
+ cp $(GLIBNAME) $(DESTDIR)$(AUTOLOAD_DIR)
+ cp $(OLIBNAME) $(DESTDIR)$(AUTOLOAD_DIR)
clean:
rm -f $(OLIBNAME) $(GLIBNAME) *.o
=====================================
README deleted
=====================================
@@ -1,63 +0,0 @@
-Standalone GRASS Drivers for GDAL and OGR
-=========================================
-
-This package contains standalone drivers for GRASS raster and vector
-files that can be built after GDAL has been built and installed as an
-"autoload" driver.
-
-This is particularly useful in resolving problems with GRASS depending
-on GDAL, but GDAL with GRASS support depending on GRASS. With this
-package you can configure and install GDAL normally (--without-grass), then
-build and install GRASS normally and finally build and install this driver.
-
-To build this driver it is necessary for it to find GDAL and GRASS support
-files. Typically the configure and build process would look something like:
-
-./configure --with-gdal=/usr/local/bin/gdal-config --with-grass=/usr/local/grass-7.0.1
-make
-sudo make install
-
-See also:
-
- https://gdal.org/
- https://grass.osgeo.org
-
-
----
-
-FAQs
-----
-
-
-Question:
-
-I am trying to install gdal-grass 3.1.3 on RedHat Enterprise Linux
-advanced server 3.0. I have previously installed gdal 3.1.3 --without-grass,
-and GRASS 7.0.1 with GDAL. I have tried to configure gdal-grass
-with:
-
-./configure --with-gdal=/usr/local/bin/gdal-config \
- --with-grass=/usr/local/grass-7.0.1
-
-It seems to find gdal alright, but then balks at the Grass location. The
-Grass location specified above is indeed the correct location. I have
-also tried adding --with-grass=/usr/local/grass-7.0.1/lib, but with no
-success. My error is:
-
-...
-checking for G_asprintf in -lgrass_gis ... no
-configure: error: --with-grass=/usr/local/grass-7.0.1 requested, but
-libraries not found?
-
-
-Answer:
-
-Your problem is likely to be solved by editing /etc/ld.so.conf to
-include the locations of proj, gdal, grass, and geos. Specifically,
-the full path to both gdal-config and geos-config, and the full paths
-to the library locations of proj (often /usr/local/lib) and grass
-(/usr/local/grass-7.0.1/lib). After editing ld.so.conf, run ldconfig,
-and you should be good to go.
-
-I ran into this problem this weekend (and posted for help to this
-list), so it seems to be a pretty common issue.
=====================================
README.md
=====================================
@@ -0,0 +1,35 @@
+## Standalone GRASS Drivers for GDAL and OGR
+
+This package contains standalone drivers for [GRASS](http://grass.osgeo.org/)
+raster and vector files that can be built after [GDAL](https://gdal.org/) has
+been built and installed as a GDAL "autoload" driver.
+
+This approach avoids circular dependencies with GRASS depending on GDAL,
+but GDAL with GRASS support depending on GRASS. With this driver package
+you configure and install GDAL normally, then build and install GRASS normally
+and finally build and install this driver.
+
+To build this driver it is necessary for it to find GDAL and GRASS
+support files. Typically the configure and build process would look
+something like:
+
+```
+./configure --with-gdal=/usr/bin/gdal-config \
+ --with-grass=/usr/grass
+make
+sudo make install
+```
+
+## Usage
+
+Access GRASS GIS raster data from GDAL:
+
+```
+gdalinfo ~/grassdata/nc_spm_08_grass7/PERMANENT/cellhd/elevation
+```
+
+Access GRASS GIS vector data from GDAL-OGR:
+
+```
+ogrinfo -so -al ~/grassdata/nc_spm_08_grass7/PERMANENT/vector/zipcodes/head
+```
=====================================
aclocal.m4
=====================================
@@ -19,11 +19,6 @@ AC_DEFUN(AC_COMPILER_LOCALHACK,
AC_DEFUN(AC_COMPILER_WFLAGS,
[
- # Remove -g from compile flags, we will add via CFG variable if
- # we need it.
- CXXFLAGS=`echo "$CXXFLAGS " | sed "s/-g //"`
- CFLAGS=`echo "$CFLAGS " | sed "s/-g //"`
-
# check for GNU compiler, and use -Wall
if test "$GCC" = "yes"; then
C_WFLAGS="-Wall"
=====================================
docs/grass_raster.md
=====================================
@@ -0,0 +1,66 @@
+# GDAL-GRASS driver: Raster Format
+
+GDAL optionally supports reading of existing GRASS GIS raster maps or
+imagery groups, but not writing or export. The support for GRASS raster
+format is determined when the library is configured, and requires
+libgrass to be pre-installed (see Notes below).
+
+GRASS raster maps/imagery groups can be selected in several ways.
+
+1. The full path to the `cellhd` file can be specified. This is not a
+ relative path, or at least it must contain all the path components
+ within the GRASS database including the database root itself. The
+ following example opens the raster map "elevation" within the GRASS
+ mapset "PERMANENT" of the GRASS location "myloc" in the GRASS
+ database located at `/data/grassdb`.
+
+ For example:
+
+ gdalinfo /data/grassdb/myloc/PERMANENT/cellhd/elevation
+
+2. The full path to the directory containing information about an
+ imagery group (or the REF file within it) can be specified to refer
+ to the whole group as a single dataset. The following examples do
+ the same thing.
+
+ For example:
+
+ gdalinfo /data/grassdb/imagery/raw/group/testmff/REF
+ gdalinfo /data/grassdb/imagery/raw/group/testmff
+
+3. If there is a correct `.grassrc7/rc` (GRASS 7) setup file in the
+ user's home directory then raster maps or imagery groups may be
+ opened just by the cell or group name. This only works for raster
+ maps or imagery groups in the current GRASS location and mapset as
+ defined in the GRASS setup file.
+
+The following features are supported by the GDAL/GRASS link.
+
+ - Up to 256 entries from raster colormaps are read (0-255).
+ - Compressed and uncompressed integer (CELL), floating point (FCELL)
+ and double precision (DCELL) raster maps are all supported. Integer
+ raster maps are classified with a band type of "Byte" if the 1-byte
+ per pixel format is used, or "UInt16" if the two byte per pixel
+ format is used. Otherwise integer raster maps are treated as
+ "UInt32".
+ - Georeferencing information is properly read from GRASS format.
+ - An attempt is made to translate coordinate systems, but some
+ conversions may be flawed, in particular in handling of datums and
+ units.
+
+## Driver capabilities
+
+## Notes on driver variations
+
+The driver is able to use the GRASS GIS shared libraries directly
+instead of using libgrass (not recommended due to potentially circular
+dependencies). Currently both versions of the driver are available and
+can be configured using `--with-libgrass` for the libgrass variant or
+`--with-grass=<dir>` for the GRASS GIS library based version. The GRASS
+driver version currently does not support coordinate system access,
+though it is hoped that will be corrected at some point.
+
+## See Also
+
+ - [GRASS GIS home page](https://grass.osgeo.org)
+ - [old libgrass page](https://web.archive.org/web/20130730111701/http://home.gdal.org/projects/grass/)
=====================================
docs/grass_raster.rst
=====================================
@@ -0,0 +1,83 @@
+.. _raster.grass:
+
+================================================================================
+GRASS Raster Format
+================================================================================
+
+.. shortname:: GRASS
+
+.. build_dependencies:: libgrass
+
+GDAL optionally supports reading of existing GRASS GIS raster maps or
+imagery groups, but not writing or export. The support for GRASS raster
+format is determined when the library is configured, and requires
+libgrass to be pre-installed (see Notes below).
+
+GRASS raster maps/imagery groups can be selected in several ways.
+
+#. The full path to the ``cellhd`` file can be specified. This is not a
+ relative path, or at least it must contain all the path components
+ within the GRASS database including the database root itself. The
+ following example opens the raster map "elevation" within the GRASS
+ mapset "PERMANENT" of the GRASS location "myloc" in the GRASS
+ database located at ``/data/grassdb``.
+
+ For example:
+
+ ::
+
+ gdalinfo /data/grassdb/myloc/PERMANENT/cellhd/elevation
+
+#. The full path to the directory containing information about an
+ imagery group (or the REF file within it) can be specified to refer
+ to the whole group as a single dataset. The following examples do the
+ same thing.
+
+ For example:
+
+ ::
+
+ gdalinfo /data/grassdb/imagery/raw/group/testmff/REF
+ gdalinfo /data/grassdb/imagery/raw/group/testmff
+
+#. If there is a correct ``.grassrc7/rc`` (GRASS 7) setup file in the
+ user's home directory then raster maps or imagery groups may be opened
+ just by the cell or group name.
+ This only works for raster maps or imagery groups in the
+ current GRASS location and mapset as defined in the GRASS setup file.
+
+The following features are supported by the GDAL/GRASS link.
+
+- Up to 256 entries from raster colormaps are read (0-255).
+- Compressed and uncompressed integer (CELL), floating point (FCELL)
+ and double precision (DCELL) raster maps are all supported. Integer
+ raster maps are classified with a band type of "Byte" if the 1-byte
+ per pixel format is used, or "UInt16" if the two byte per pixel
+ format is used. Otherwise integer raster maps are treated as
+ "UInt32".
+- Georeferencing information is properly read from GRASS format.
+- An attempt is made to translate coordinate systems, but some
+ conversions may be flawed, in particular in handling of datums and
+ units.
+
+Driver capabilities
+-------------------
+
+.. supports_georeferencing::
+
+Notes on driver variations
+--------------------------
+
+The driver is able to use the GRASS GIS shared libraries directly
+instead of using libgrass (not recommended due to potentially circular
+dependencies). Currently both versions of the driver are available and
+can be configured using ``--with-libgrass`` for the libgrass variant or
+``--with-grass=<dir>`` for the GRASS GIS library based version. The
+GRASS driver version currently does not support coordinate system
+access, though it is hoped that will be corrected at some point.
+
+See Also
+--------
+
+- `GRASS GIS home page <https://grass.osgeo.org>`__
+- `libgrass page <https://web.archive.org/web/20130730111701/http://home.gdal.org/projects/grass/>`__
=====================================
docs/grass_vector.md
=====================================
@@ -0,0 +1,113 @@
+# GDAL-GRASS driver: Vector Format
+
+The GDAL-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.
+
+## Driver capabilities
+
+## Datasource name
+
+Datasource name is full path to 'head' file in GRASS vector directory.
+Using names of GRASS environment variables it can be expressed:
+
+ $GISDBASE/$LOCATION_NAME/$MAPSET/vector/mymap/head
+
+where 'mymap' is name of a vector map. For example:
+
+ /home/cimrman/grass_data/jizerky/jara/vector/liptakov/head
+
+## Layer names
+
+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 original record:
+
+ 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'.
+
+## Attribute filter
+
+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.
+
+## Spatial filter
+
+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
+
+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.
+
+## Missing topology
+
+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 v.build
+module.
+
+## Random access
+
+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.
+
+## Known problem
+
+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.
+
+## See Also
+
+ - [GRASS GIS home page](https://grass.osgeo.org)
+ - [old libgrass page](https://web.archive.org/web/20130730111701/http://home.gdal.org/projects/grass/)
+
+-----
+
+Development of this driver was financially supported by Faunalia
+([www.faunalia.it](http://www.faunalia.it/)).
=====================================
docs/grass_vector.rst
=====================================
@@ -0,0 +1,139 @@
+.. _vector.grass:
+
+GRASS Vector Format
+===================
+
+.. shortname:: GRASS
+
+.. build_dependencies:: libgrass
+
+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.
+
+Driver capabilities
+-------------------
+
+.. supports_georeferencing::
+
+Datasource name
+---------------
+
+Datasource name is full path to 'head' file in GRASS vector directory.
+Using names of GRASS environment variables it can be expressed:
+
+::
+
+ $GISDBASE/$LOCATION_NAME/$MAPSET/vector/mymap/head
+
+where 'mymap' is name of a vector map. For example:
+
+::
+
+ /home/cimrman/grass_data/jizerky/jara/vector/liptakov/head
+
+Layer names
+-----------
+
+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 original record:
+
+::
+
+ 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'.
+
+Attribute filter
+----------------
+
+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.
+
+Spatial filter
+--------------
+
+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
+-------
+
+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.
+
+Missing topology
+----------------
+
+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 v.build
+module.
+
+Random access
+-------------
+
+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.
+
+Known problem
+-------------
+
+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.
+
+See Also
+--------
+
+- `GRASS GIS home page <http://grass.osgeo.org>`__
+
+--------------
+
+Development of this driver was financially supported by Faunalia
+(`www.faunalia.it <http://www.faunalia.it/>`__).
=====================================
grass.cpp
=====================================
@@ -53,6 +53,8 @@ extern "C" {
char *GPJ_grass_to_wkt( const struct Key_Value *,
const struct Key_Value *,
int, int );
+
+void GDALRegister_GRASS();
}
#define GRASS_MAX_COLORS 100000 // what is the right value
=====================================
ogrgrassdriver.cpp
=====================================
@@ -30,6 +30,10 @@
#include "cpl_conv.h"
#include "cpl_string.h"
+extern "C" {
+ void RegisterOGRGRASS();
+}
+
CPL_CVSID("$Id$")
/************************************************************************/
View it on GitLab: https://salsa.debian.org/debian-gis-team/gdal-grass/-/commit/a062b4b77f3e86eb724d61c1fee963f96546758b
--
View it on GitLab: https://salsa.debian.org/debian-gis-team/gdal-grass/-/commit/a062b4b77f3e86eb724d61c1fee963f96546758b
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20220614/bf23445f/attachment-0001.htm>
More information about the Pkg-grass-devel
mailing list