On Tue, Oct 11, 2016 at 12:11:06PM +0200, Even Rouault wrote:
> > According to this:
> > http://devzone.advantagedatabase.com/dz/webhelp/advantage9.0/server1/dbf_fi
> > eld_types_and_specifications.htm
> > 
> > A DBF field with extended data type "double" does not affect the
> > precision of the stored data, and the length information is simply
> > ignored.
> I had never seen such "double" type in use in .dbf, and it is certainly not 
> handled by shapelib/OGR, and I have never seen reports that other shapefile 
> producing software generate such field types. Might be a "Visual FoxPro" 
> specific thing.

So what are those OFTReal types coming from ?
According to shapelib, the test shapefile field type is:

 Field shape_area is an FTDouble with width 19 and precision 11

> > After all, a "Double" in a DBF is just 8 bytes anyway, so why bother
> > attempting to go beyond that ? Qgis is storing values in a Double too,
> > and the only reason I see to support "numeric" is storing arbitrary
> > precision values, which don't seem to be supported by OGR:
> > http://www.gdal.org/ogr__core_8h.html#a787194bea637faf12d61643124a7c9fc
> True, OGR ends up storing numeric fields as C double. The width/precision is 
> mostly informative (and occasionnaly indeed an annoyance when backends start 
> using it...)

Ok so my proposed fix for issue 15188 is simply to revert
the PR, which is the one making (mis)use of that information
while writing in the database.

Qgis-developer mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to