Extend v.in.ogr to use GDAL/OGR-GMLAS driver

[gisix]

Hi, GDAL/OGR features a new extended driver for complex GML-data which currently can't be accessed from a GRASS environment. This driver (GMLAS) extends the run-of-the-mill GML-capabilities available to GRASS users significantly. Please add parameters/flags for v.in.ogr to make use of this GDAL functionality.

best, Peter

[mmetz]

v.in.ogr can import any data formats supported by GDAL/OGR, no special parameters/flags needed. For example, if GDAL/OGR supports GMLAS, GMLAS data can be imported, granted that the contents are supported by GRASS. Note that the contents are not GMLAS specific.

GMLAS test data of GDAL/OGR at ​https://github.com/OSGeo/gdal/tree/master/autotest/ogr/data/gmlas/real_world are imported just fine.

Closing as invalid, please reopen if there is need for particular parameters/flags related to GMLAS.

[gisix]

Please reopen this ticket and reconsider whether this is really invalid for GIS users wanting to work with nontrivial contemporary 3D GML in GRASS GIS:

1) GDAL as it is currently configured in GRASS 7.6.1 does *NOT* include the GMLAS driver for nontrivial GML/XML. So v.in.ogr currently does *NOT* import nontrivial GML/XML: Opening a complex GML-based file like european CityGML datasets by explicitly choosing the advanced GMLAS driver instead of the default GML driver throws an error message. If folks want to work with complex 3D GML, they will need to do so outside a GRASS environment. 2) The GMLAS driver of GDAL/OGR would allow to work in GRASS with 3D PolyhedralSurfaces encoded as nontrivial GML. 3)3D PolyhedralSurfaces will either either require functionality for the users on the GRASS module level (i.e. a flag or similar for v.in.ogr) to flatten 3D polyhedral surfaces into a GRASS 2D vector topology, 4) or a means to provide additional parameters to the underlying GDAL/OGR environment, similar to the query_layer parameter of v.to.db (https://grass.osgeo.org/grass70/manuals/v.to.db.html)

[mmetz]

Replying to gisix:

1) GDAL as it is currently configured in GRASS 7.6.1 does *NOT* include the GMLAS driver for nontrivial GML/XML.

GDAL is *NOT* configured in GRASS, GDAL is independent of GRASS. That means if a particular OGR driver is available in OGR or not is independent of GRASS, there is nothing GRASS can do about it. Please compile GDAL from source or contact the maintainer of the GDAL package for your operating system.

2) The GMLAS driver of GDAL/OGR would allow to work in GRASS with 3D PolyhedralSurfaces encoded as nontrivial GML.

No, there is no mechanism in GRASS to convert PolyhedralSurfaces to another geometry type. You can try ogr2ogr -nlt MULTIPOLYGONZ, see ​https://gdal.org/programs/ogr2ogr.html, but as mentioned in the link in ​https://lists.osgeo.org/pipermail/grass-user/2019-August/080599.html, "Note that converting a TIN or a PolyhedralSurface into a MultiPolygon is semantically incorrect since a MultiPolygon is supposed to contain geometries in the same plane, but it might help when converting those new geometry types into a format that doesn’t support them", converting a PolyhedralSurface into a MultiPolygon is technically possible, at the risk of getting garbage. Note that PolyhedralSurfaces are not restricted to GMLAS, they are a new geometry type of simple features supported by a few data formats like GMLAS.

3)3D PolyhedralSurfaces will either either require functionality for the users on the GRASS module level (i.e. a flag or similar for v.in.ogr) to flatten 3D polyhedral surfaces into a GRASS 2D vector topology,

As above, technically possible at the risk of getting garbage, try ogr2ogr -nlt MULTIPOLYGONZ instead. IMHO it is a bad idea to make v.in.ogr convert otherwise valid data into potential garbage.

4) or a means to provide additional parameters to the underlying GDAL/OGR environment, similar to the query_layer parameter of v.to.db (https://grass.osgeo.org/grass70/manuals/v.to.db.html)

Already implemented in v.in.ogr with the options gdal_config and gdal_doo.