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 [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
