#792: dbf driver: wrong column data type
-------------------------+--------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Keywords: data type | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
DBF driver in GRASS 7 reports 'double' even if decimals is zero, e.g.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:1 mmetz]:
> I would first like to know why in grass7 integer fields with width > 10
are considered double, contrary to grass6.x.
>
> See also gdal ticket 809.
Right, same problem with 'OGR' driver. There is no info about decimals
[1].The attached patch is ugly workaround which cannot be applied in OGR
driver.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:1 mmetz]:
> In particular, why does the Makefile for the dbf driver now include
$(GDALLIBS) but not in grass6.x?
In the result dbf driver uses GDAL not ShapeLib. Removing $(GDALLIBS) from
Makefile would be a quick solution. Anyway there is still problem with OGR
driver. For every OGR layers is key column (if defined) reported as
'double' which breaks most of GRASS modules.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by mmetz):
Replying to [comment:3 martinl]:
> Replying to [comment:1 mmetz]:
> > In particular, why does the Makefile for the dbf driver now include
$(GDALLIBS) but not in grass6.x?
>
> In the result dbf driver uses GDAL not ShapeLib. Removing $(GDALLIBS)
from Makefile would be a quick solution.
Sure, but I guess there is a reason for the new presence of $(GDALLIBS)
for the dbf driver? It seems it was added by Glynn in r38906. But it's
working fine after I removed $(GDALLIBS) from the Makefile.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):
Replying to [comment:5 hamish]:
> could you post here which DBF from the nc_ dataset you are using for
tests?
fyi,
{{{
$ dbview -e grassdata/nc_spm_08/PERMANENT/dbf/geology.dbf | head
Field Name Type Length Decimal Pos
cat N 11 0
onemap pro N 20 6
Perimeter N 20 6
Geol250 N 11 0
Geol250 id N 11 0
Geo name C 6 0
Shape area N 20 6
Shape len N 20 6
}}}
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:5 hamish]:
> could you post here which DBF from the nc_ dataset you are using for
tests?
Sorry, I am not getting the point. AFAIU problem is a bug in GDAL/OGR when
as a result 'integer' is detected as 'double precision', the very same for
OGR driver in GRASS of course.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:6 hamish]:
> Replying to [comment:5 hamish]:
> > could you post here which DBF from the nc_ dataset you are using for
tests?
{{{
> $ dbview -e grassdata/nc_spm_08/PERMANENT/dbf/geology.dbf | head
>
> Field Name Type Length Decimal Pos
> cat N 11 0
> onemap pro N 20 6
> Perimeter N 20 6
> Geol250 N 11 0
> Geol250 id N 11 0
> Geo name C 6 0
> Shape area N 20 6
> Shape len N 20 6
}}}
Problem are not the data, but the bug in OGR. If you use OGR for reading
dbf, 'cat' is detected as 'double precision', same for PostGIS layer
connected by OGR driver, etc.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):
Replying to [comment:4 mmetz]:
> > > In particular, why does the Makefile for the dbf driver now include
$(GDALLIBS) but not in grass6.x?
> Sure, but I guess there is a reason for the new presence of $(GDALLIBS)
for the dbf driver? It seems it was added by Glynn in r38906. But it's
working fine after I removed $(GDALLIBS) from the Makefile.
r38906 was a scripted change which matched each program with the libraries
which exported the symbols which were imported by the program. In the case
of the DBF driver, the program imports the various DBF* symbols, GDAL
exports these symbols, therefore $(GDALLIBS) was added to the Makefile.
The process didn't handle the case where the imported symbols are exported
by multiple libraries (in this case, GDAL and !ShapeLib). AFAICT, the DBF
driver is the only program which uses !ShapeLib.
#792: dbf driver: wrong column data type
--------------------------+-------------------------------------------------
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Resolution: | Keywords: data type
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by mmetz):
Replying to [comment:9 glynn]:
> Replying to [comment:4 mmetz]:
>
> > > > In particular, why does the Makefile for the dbf driver now
include $(GDALLIBS) but not in grass6.x?
>
> > Sure, but I guess there is a reason for the new presence of
$(GDALLIBS) for the dbf driver? It seems it was added by Glynn in r38906.
But it's working fine after I removed $(GDALLIBS) from the Makefile.
>
> r38906 was a scripted change which matched each program with the
libraries which exported the symbols which were imported by the program.
In the case of the DBF driver, the program imports the various DBF*
symbols, GDAL exports these symbols, therefore $(GDALLIBS) was added to
the Makefile.
>
> The process didn't handle the case where the imported symbols are
exported by multiple libraries (in this case, GDAL and !ShapeLib). AFAICT,
the DBF driver is the only program which uses !ShapeLib.
Ah, ok. Reading around a bit (documentation and previous discussions), it
seems that the dbf driver is supposed to use !Shapelib instead of GDAL. I
removed $(GDALLIBS) from the Makefile in r39594 (it's not the first time
that is done), works for me, please test.
#792: dbf driver: wrong column data type
----------------------------+-----------------------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-trunk
Keywords: dbf, data type | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Changes (by neteler):
* keywords: data type => dbf, data type
Comment:
Replying to [comment:10 mmetz]:
> Replying to [comment:9 glynn]:
> > Replying to [comment:4 mmetz]:
...
> > The process didn't handle the case where the imported symbols are
exported by multiple libraries (in this case, GDAL and !ShapeLib). AFAICT,
the DBF driver is the only program which uses !ShapeLib.
>
> Ah, ok. Reading around a bit (documentation and previous discussions),
it seems that the dbf driver is supposed to use !Shapelib instead of GDAL.
I removed $(GDALLIBS) from the Makefile in r39594 (it's not the first time
that is done), works for me, please test.
Is there a reason to keep the private (older) shapelib copy instead of
using GDAL?