[pdal] Writers.copc changes global encoding
Andrew Bell
andrew.bell.ia at gmail.com
Tue Mar 24 07:39:26 PDT 2026
Hi Jukka,
There is nothing in the LAS specification that I saw that requires a
limited range of values of GPS time based on the bit in the global encoding
field. People write lots of data that isn't what one would expect and PDAL
has generally let such things pass rather than error, though sometimes we
emit a warning. Note that you can set the global encoding field to whatever
value you like with the "--global_encoding" option.
Untwine does attempt to use the default type (see
https://pdal.org/en/latest/dimensions.html) for dimensions that aren't part
of the LAS standard, though I believe this capability was added more
recently. You can certainly limit which dimensions are written by using the
`dims` options, though LAS specifies dimensions for each point data format
-- if dimensions are excluded or missing in the input but necessary for
output they will be set to zero.
I'd have to have data and a specific command line to comment further.
Perhaps there is a bug and you're welcome to submit a complete issue.
On Tue, Mar 24, 2026 at 10:01 AM <jukka.rahkonen at latuviitta.fi> wrote:
> Hi,
>
> There seems to be a lot to learn, but I am making progress. The size
> differences are due to extra attributes. Basic pdal command drops them
> (-> smaller file), and the untwine command expands short and ushort type
> attributes into doubles (-> bigger file).
> Partial pdal solution is to define the exact datatypes
> "extra_dims":"Amplitude=ushort,Reflectance=short,Deviation=ushort"
> What I have not discovered yet is how to scale these dims by 0.01.
>
> -Jukka Rahkonen-
>
>
> jukka.rahkonen at latuviitta.fi kirjoitti 2026-03-24 09:42:
> > Hi Andrew,
> >
> > Thanks, I understand now. I was just surprised because the usage
> > example https://pdal.org/en/stable/stages/writers.copc.html#example
> > seemed to create an invalid output. Maybe there could be a note for new
> > users that the simplistic command drops the source headers.
> >
> > I also noticed that with my test data writers.copc creates about 30 %
> > smaller COPC files than lascopcindex. And untwine writes 75 % bigger
> > files than lascopcindex. Do these differences feel reasonable, or
> > should I think that I am doing something badly wrong?
> > The number of point records is for example 51749964, and my
> > lascopcindex and untwine commands were simply
> > lascopcindex64 M4131D2_1.las
> > untwine -i M4131D2_1.las -o M4131D2_1_untwine.copc.laz
> > The pdal pipeline appears in my previous mail.
> >
> > -Jukka Rahkonen-
> >
> > Andrew Bell kirjoitti 2026-03-24 00:21:
> >> Hi Jukka,
> >>
> >> This is expected behavior. Header values from LAS files aren't
> >> forwarded unless you request it.
> >>
> >> On Mon, Mar 23, 2026 at 4:46 PM Jukka Rahkonen via pdal
> >> <pdal at lists.osgeo.org> wrote:
> >>
> >>> Hi,
> >>>
> >>> I had my first trials with PDAL and COPC but something seems to go
> >>> wrong
> >>> with global encoding.
> >>> My PDAL version is pdal 2.10.0 (git-version: Release). Lasinfo about
> >>> my
> >>> source data shows
> >>>
> >>> lasinfo (260311) report for 'M4131D2_1.las'
> >>> reporting all LAS header entries:
> >>> file signature: 'LASF'
> >>> file source ID: 0
> >>> global_encoding: 17
> >>> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> >>> version major.minor: 1.4
> >>> system identifier: 'LAStools (c) by rapidlasso GmbH'
> >>> generating software: 'las2las64 (version 231227)'
> >>>
> >>> My pipeline is simply
> >>>
> >>> [
> >>> "M4131D2_1.las",
> >>> {
> >>> "type":"writers.copc",
> >>> "filename":"M4131D2_1_pdal.copc.laz"
> >>> }
> >>> ]
> >>>
> >>> And lasinfo shows for me
> >>>
> >>> lasinfo (260311) report for 'M4131D2_1_pdal.copc.laz'
> >>> reporting all LAS header entries:
> >>> file signature: 'LASF'
> >>> file source ID: 0
> >>> global_encoding: 16
> >>> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> >>> version major.minor: 1.4
> >>> system identifier: 'PDAL'
> >>> generating software: 'PDAL 2.10.0 (Releas)'
> >>>
> >>> Because global_encoding has changed from 17 into 16, check with
> >>> lasvalidate fails:
> >>>
> >>> <fail>
> >>> <variable>global encoding</variable>
> >>> <note>unset bit 0 suggests GPS week time but GPS time
> >>> ranges
> >>> from 433432315.217674 to 433434074.507472</note>
> >>> </fail>
> >>>
> >>> The error disappears if I add "forward":"all" into the pipeline but
> >>> shouldn't the global_encoding value remain the same even without?
> >>>
> >>> -Jukka Rahkonen-
> >>> _______________________________________________
> >>> pdal mailing list
> >>> pdal at lists.osgeo.org
> >>> https://lists.osgeo.org/mailman/listinfo/pdal
> >>
> >> --
> >>
> >> Andrew Bellandrew.bell.ia at gmail.com
>
--
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20260324/94f96a9a/attachment.htm>
More information about the pdal
mailing list