GRASS OGR driver: 2D maps read as 3D

[hamish]

Hi,

forwarded from the GRASS-stats mailing list (i.e. GRASS <-> R-stats linkage which uses the gdal+ogr drivers for data transport)

Roger Bivand wrote:

The plugin also creates a fictitious third dimension in (point at least) data that has created havoc, and has led to readVECT6() getting a pointDropZ= argument - that's why it says that wkbPoint is 3 with the plugin and (correctly) 2 otherwise.

[...]

OK, looks like calls to Vect_is_3d(poMap) missing in *OGRGRASSLayer::GetFeatureGeometry about lines after 851 in ogf_frmts/grass/ogrgrasslayer.cpp; the problem exists for all geometry types, just emitting a z value even if the vect is 2D. I can't see that Vect_read_line returns z as NULL if not 3D - Vect_is_3d() is not used much in lib/vector/*.

see the thread here,

​http://lists.osgeo.org/pipermail/grass-stats/2009-May/001049.html

there is also another problem discussed in that post whereas the GRASS/OGR driver is horribly slow when using the SQLite DB backend with many attribute columns. Waiting on isolating it and generating a test case before filing a bug for that.

Hamish

[Even Rouault]

For the 2D geometries reported as 3D, I've commited a fix in trunk in r17122.