[gdal-dev] What are vector field width and precision good for?
Even Rouault
even.rouault at spatialys.com
Sun Oct 6 02:19:35 PDT 2024
Sean,
>
> Would the defaults result in overly large attribute files? By a small
> amount or an excessive amount? Or would the defaults result in
> truncation of values?
For shapefile the default is width=24,precision=15,so this means 24
bytes for every floating point number. In theory a number couldn't have
a magnitude larger than 10^(24-15-1), but the shapefile driver will
remove decimal figures if that's needed to preserve the integer part.
But if a number is larger than 10^24, its last digits will just be
truncated with a warning (there's no good solution here. I kind of
remember of past discussions if we shouldn't fallback to scientific
notation, but we didn't implement that). In that situation, the user
would have to increase the width (one can question the appropriateness
of using Shapefile .dbf for numbers of very large magnitude). So
basically the default should be fine (as far as preserving information
is concerned) for most common ranges of floating point numbers, but will
misbehave for very large ones. Obviously for people storing small
numbers with few decimals, 24 might be felt as excessive.
For MapInfo I was actually partially incorrect. It has indeed a mode of
fixed precision, but if you don't specify the width, it uses IEEE754
double precision for .tab, et a non-fixed width text representation for
.mif.
Shapefiles are (probably) the only format OGR handles on the writing
side that require, explicit or implict, width.precision (PostGIS or
other databases are similar to MapInfo and support both fixed
width/precision and floating-point)
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
More information about the gdal-dev
mailing list