> 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. > > 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...) > > --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 -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ 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