GRASS OGR driver: 2D maps read as 3D
|Reported by:||hamish||Owned by:||Even Rouault|
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,
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.