[gdal-dev] gdal-dev Digest, Vol 245, Issue 7

Vincent Autieri II vautieri at geoweb3d.com
Mon Oct 7 07:50:17 PDT 2024


HELP  unsubscribe please

On Sun, Oct 6, 2024 at 3:00 PM <gdal-dev-request at lists.osgeo.org> wrote:

> Send gdal-dev mailing list submissions to
>         gdal-dev at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.osgeo.org/mailman/listinfo/gdal-dev
> or, via email, send a message with subject or body 'help' to
>         gdal-dev-request at lists.osgeo.org
>
> You can reach the person managing the list at
>         gdal-dev-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gdal-dev digest..."
>
>
> Today's Topics:
>
>    1. What are vector field width and precision good for? (Sean Gillies)
>    2. Re: What are vector field width and precision good for?
>       (Even Rouault)
>    3. Re: What are vector field width and precision good for?
>       (Sean Gillies)
>    4. Re: What are vector field width and precision good for?
>       (Even Rouault)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 5 Oct 2024 16:38:14 -0600
> From: Sean Gillies <sean.gillies at gmail.com>
> To: gdal dev <gdal-dev at lists.osgeo.org>
> Subject: [gdal-dev] What are vector field width and precision good
>         for?
> Message-ID:
>         <CAOodmJo26kYqC=M_3PHNJwzK=
> 3Q0UdjLDZKxJg0JwwkNW5774A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> What are vector field width and precision good for in 2024? These concepts
> were inherited from MS Access via Shapefile, I believe. I've been wondering
> if I can stop supporting them in my Fiona project without breaking
> workflows badly. Numpy data types don't have width and precision. Neither
> do, for example, Parquet and Arrow.
>
> Anybody using these for anything crucial?
>
> --
> Sean Gillies
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241005/1495d2c5/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 6 Oct 2024 00:48:09 +0200
> From: Even Rouault <even.rouault at spatialys.com>
> To: Sean Gillies <sean.gillies at gmail.com>, gdal dev
>         <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] What are vector field width and precision good
>         for?
> Message-ID: <bcdc66c7-6002-41c3-96bb-0498e2c738ba at spatialys.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Sean,
>
> > What are vector field width and precision good for in 2024? These
> > concepts were inherited from MS Access via Shapefile, I believe. I've
> > been wondering if I can stop supporting them in my Fiona project
> > without breaking workflows badly. Numpy data types don't have width
> > and precision. Neither do, for example, Parquet and Arrow.
> >
> > Anybody using these for anything crucial?
>
> If Fiona had only a read side you could likely ignore them.? But writing
> all those formats (shapefile, mapinfo, etc.) require setting those
> properties. If you don't specify them, the OGR drivers will use some
> defaults, that might not always be appropriate.
>
> Even
>
> --
>
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 5 Oct 2024 17:32:18 -0600
> From: Sean Gillies <sean.gillies at gmail.com>
> To: gdal dev <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] What are vector field width and precision good
>         for?
> Message-ID:
>         <
> CAOodmJocW4yVShE_yacvUMFyLfo04p0oToB+Zzoevt1AsZJr0w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Even,
>
> 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?
>
> On Sat, Oct 5, 2024 at 4:48?PM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
> > Sean,
> >
> > > What are vector field width and precision good for in 2024? These
> > > concepts were inherited from MS Access via Shapefile, I believe. I've
> > > been wondering if I can stop supporting them in my Fiona project
> > > without breaking workflows badly. Numpy data types don't have width
> > > and precision. Neither do, for example, Parquet and Arrow.
> > >
> > > Anybody using these for anything crucial?
> >
> > If Fiona had only a read side you could likely ignore them.  But writing
> > all those formats (shapefile, mapinfo, etc.) require setting those
> > properties. If you don't specify them, the OGR drivers will use some
> > defaults, that might not always be appropriate.
> >
> > Even
> >
>
>
> --
> Sean Gillies
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241005/b4c449ad/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 6 Oct 2024 11:19:35 +0200
> From: Even Rouault <even.rouault at spatialys.com>
> To: Sean Gillies <sean.gillies at gmail.com>, gdal dev
>         <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] What are vector field width and precision good
>         for?
> Message-ID: <a4668df8-5d70-49fe-be5a-f57ee09980bf at spatialys.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ------------------------------
>
> End of gdal-dev Digest, Vol 245, Issue 7
> ****************************************
>


-- 
*Vincent Autieri*
Vice President Co-Founder, Geoweb3d Inc.
607-323-1114 <607-731-3904> | vautieri at geoweb3d.com |
http://www.geoweb3d.com

IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241007/965c0edd/attachment-0001.htm>


More information about the gdal-dev mailing list