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.

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

Reply via email to