[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