[GRASS-dev] [GRASS GIS] #3890: Extend v.in.ogr to use GDAL/OGR-GMLAS driver

GRASS GIS trac at osgeo.org
Tue Aug 13 05:22:51 PDT 2019

#3890: Extend v.in.ogr to use GDAL/OGR-GMLAS driver
  Reporter:  gisix        |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  closed
  Priority:  normal       |  Milestone:
 Component:  Vector       |    Version:  svn-trunk
Resolution:  invalid      |   Keywords:
       CPU:  Unspecified  |   Platform:  Unspecified

Comment (by mmetz):

 Replying to [comment:2 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

 > 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
 "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

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

Ticket URL: <https://trac.osgeo.org/grass/ticket/3890#comment:3>
GRASS GIS <https://grass.osgeo.org>

More information about the grass-dev mailing list