From jukka.rahkonen at latuviitta.fi  Mon Mar 23 12:41:28 2026
From: jukka.rahkonen at latuviitta.fi (jukka.rahkonen at latuviitta.fi)
Date: Mon, 23 Mar 2026 21:41:28 +0200
Subject: [pdal] Writers.copc changes global encoding
In-Reply-To: <CACJ51z0MY=Zy_cMmb0o0Au4Xm0ZVTa2s7GW8esV2uGfb32gN4Q@mail.gmail.com>
References: <CAGZyQoO97-2EPsJGQt+-JA2WVVCWTvYjnkQp=_hDPCp+6eBGEA@mail.gmail.com>
 <CACJ51z0MY=Zy_cMmb0o0Au4Xm0ZVTa2s7GW8esV2uGfb32gN4Q@mail.gmail.com>
Message-ID: <e907e0d4c02283b6f201dcf831283752@latuviitta.fi>

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-

From kirk.waters at noaa.gov  Tue Mar 24 05:40:42 2026
From: kirk.waters at noaa.gov (Kirk Waters - NOAA Federal)
Date: Tue, 24 Mar 2026 08:40:42 -0400
Subject: [pdal] filters.reprojection with WKT and no EPSG
Message-ID: <CADm=QrRT=JCat+sjMn2EgLsY9-TemO8-hcg-0oKqbFDwxE+-gw@mail.gmail.com>

Dear PDAL (and maybe GDAL) gurus,
I'm trying to figure out a reprojection issue where the output projection
lacks an EPSG code. I think it should work with a WKT, but I get this error:
(pdal pipeline filters.reprojection Error) GDAL failure (1) No inverse
operation

The projection is from geographic NAD83(CORS96) to UTM zone 10 in the same
system.
Here's a simplification of the pipeline I'm trying to run:
[
  {
    "type": "readers.las",
    "filename": "
https://coast.noaa.gov/htdata/lidar1_z/tmp/20180316_WA_Olympic_Peninsula_C1_2017_46123H5107_1.copc.laz
"
  },
  {
    "type": "filters.reprojection",
    "in_srs": "EPSG:6783+5703",
    "out_srs": "COMPD_CS[\"NAD83(CORS96) / UTM Zone 10N + NAVD88
height\",PROJCS[\"NAD83(CORS96) / UTM Zone
10N\",GEOGCS[\"NAD83(CORS96)\",DATUM[\"NAD83_Continuously_Operating_Reference_Station_1996\",SPHEROID[\"GRS
1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],AUTHORITY[\"EPSG\",\"1133\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"6782\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-123],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]],VERT_CS[\"NAVD88
height\",VERT_DATUM[\"North American Vertical Datum
1988\",2005],UNIT[\"metre\",1],AXIS[\"Gravity-related
height\",UP],AUTHORITY[\"EPSG\",\"5703\"]]]"
  },
  {
    "type": "writers.copc",
    "pipeline": true,
    "forward": "header, vlr",
    "offset_x": "auto",
    "offset_y": "auto",
    "offset_z": "auto",
    "extra_dims": "all",
    "filename": "pipeline10.copc.laz"
  }
]

If I switch the output srs to be "EPSG:6339+5703", I get no errors (6339 is
UTM zone 10 for NAD83(2011)), though I don't think it actually shifted from
CORS96 to 2011. GDAL osr.SpatialReference doesn't dislike the CORS96 utm 10
wkt, but it throws an exception if I try to AutoIndentifyEPSG().

Is this the intended behavior or am I doing something wrong? I'm guessing
it's related to the lack of an EPSG code, but perhaps I've gone down the
wrong path.

Note that the input file in the example uses EPSG:6782, but I simplified
the pipeline by removing the geoid application part.

Thanks for any pointers.

Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
coast.noaa.gov/digitalcoast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20260324/437faded/attachment.htm>

From kirk.waters at noaa.gov  Tue Mar 24 06:00:41 2026
From: kirk.waters at noaa.gov (Kirk Waters - NOAA Federal)
Date: Tue, 24 Mar 2026 09:00:41 -0400
Subject: [pdal] filters.reprojection with WKT and no EPSG
In-Reply-To: <CADRrdKsS5PaUrUrKKCnc-8mXOD6=ccRdpNGZocHoh0nVSmtd4A@mail.gmail.com>
References: <CADm=QrRT=JCat+sjMn2EgLsY9-TemO8-hcg-0oKqbFDwxE+-gw@mail.gmail.com>
 <CADRrdKsS5PaUrUrKKCnc-8mXOD6=ccRdpNGZocHoh0nVSmtd4A@mail.gmail.com>
Message-ID: <CADm=QrSeM+mFkaMqpfdCt+K6r00sFVcJ5YjnZx7R__nK6=nXVA@mail.gmail.com>

Javier,
Thanks. I don't know that I ever would have seen that I had that wrong.

Kirk


On Tue, Mar 24, 2026 at 8:53?AM Javier Jimenez Shaw <j1 at jimenezshaw.com>
wrote:

> I think the problem is in the definition of the geographic system
> It has AUTHORITY["EPSG","6782"], that is a geographic 3D CRS. You cannot
> combine it with a vertical system
>
> Replace it with AUTHORITY["EPSG","6783"], that is the geographic 2D
> version.
>
> On Tue, 24 Mar 2026 at 13:41, Kirk Waters - NOAA Federal via pdal <
> pdal at lists.osgeo.org> wrote:
>
>> Dear PDAL (and maybe GDAL) gurus,
>> I'm trying to figure out a reprojection issue where the output projection
>> lacks an EPSG code. I think it should work with a WKT, but I get this error:
>> (pdal pipeline filters.reprojection Error) GDAL failure (1) No inverse
>> operation
>>
>> The projection is from geographic NAD83(CORS96) to UTM zone 10 in the
>> same system.
>> Here's a simplification of the pipeline I'm trying to run:
>> [
>>   {
>>     "type": "readers.las",
>>     "filename": "
>> https://coast.noaa.gov/htdata/lidar1_z/tmp/20180316_WA_Olympic_Peninsula_C1_2017_46123H5107_1.copc.laz
>> "
>>   },
>>   {
>>     "type": "filters.reprojection",
>>     "in_srs": "EPSG:6783+5703",
>>     "out_srs": "COMPD_CS[\"NAD83(CORS96) / UTM Zone 10N + NAVD88
>> height\",PROJCS[\"NAD83(CORS96) / UTM Zone
>> 10N\",GEOGCS[\"NAD83(CORS96)\",DATUM[\"NAD83_Continuously_Operating_Reference_Station_1996\",SPHEROID[\"GRS
>> 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],AUTHORITY[\"EPSG\",\"1133\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"6782\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-123],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]],VERT_CS[\"NAVD88
>> height\",VERT_DATUM[\"North American Vertical Datum
>> 1988\",2005],UNIT[\"metre\",1],AXIS[\"Gravity-related
>> height\",UP],AUTHORITY[\"EPSG\",\"5703\"]]]"
>>   },
>>   {
>>     "type": "writers.copc",
>>     "pipeline": true,
>>     "forward": "header, vlr",
>>     "offset_x": "auto",
>>     "offset_y": "auto",
>>     "offset_z": "auto",
>>     "extra_dims": "all",
>>     "filename": "pipeline10.copc.laz"
>>   }
>> ]
>>
>> If I switch the output srs to be "EPSG:6339+5703", I get no errors (6339
>> is UTM zone 10 for NAD83(2011)), though I don't think it actually shifted
>> from CORS96 to 2011. GDAL osr.SpatialReference doesn't dislike the CORS96
>> utm 10 wkt, but it throws an exception if I try to AutoIndentifyEPSG().
>>
>> Is this the intended behavior or am I doing something wrong? I'm guessing
>> it's related to the lack of an EPSG code, but perhaps I've gone down the
>> wrong path.
>>
>> Note that the input file in the example uses EPSG:6782, but I simplified
>> the pipeline by removing the geoid application part.
>>
>> Thanks for any pointers.
>>
>> Kirk Waters, PhD
>> NOAA Office for Coastal Management
>> Applied Sciences Program
>> coast.noaa.gov/digitalcoast
>>
>>
>> _______________________________________________
>> pdal mailing list
>> pdal at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pdal
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20260324/a8f31958/attachment.htm>

From j1 at jimenezshaw.com  Tue Mar 24 05:53:15 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Tue, 24 Mar 2026 13:53:15 +0100
Subject: [pdal] filters.reprojection with WKT and no EPSG
In-Reply-To: <CADm=QrRT=JCat+sjMn2EgLsY9-TemO8-hcg-0oKqbFDwxE+-gw@mail.gmail.com>
References: <CADm=QrRT=JCat+sjMn2EgLsY9-TemO8-hcg-0oKqbFDwxE+-gw@mail.gmail.com>
Message-ID: <CADRrdKsS5PaUrUrKKCnc-8mXOD6=ccRdpNGZocHoh0nVSmtd4A@mail.gmail.com>

I think the problem is in the definition of the geographic system
It has AUTHORITY["EPSG","6782"], that is a geographic 3D CRS. You cannot
combine it with a vertical system

Replace it with AUTHORITY["EPSG","6783"], that is the geographic 2D version.

On Tue, 24 Mar 2026 at 13:41, Kirk Waters - NOAA Federal via pdal <
pdal at lists.osgeo.org> wrote:

> Dear PDAL (and maybe GDAL) gurus,
> I'm trying to figure out a reprojection issue where the output projection
> lacks an EPSG code. I think it should work with a WKT, but I get this error:
> (pdal pipeline filters.reprojection Error) GDAL failure (1) No inverse
> operation
>
> The projection is from geographic NAD83(CORS96) to UTM zone 10 in the same
> system.
> Here's a simplification of the pipeline I'm trying to run:
> [
>   {
>     "type": "readers.las",
>     "filename": "
> https://coast.noaa.gov/htdata/lidar1_z/tmp/20180316_WA_Olympic_Peninsula_C1_2017_46123H5107_1.copc.laz
> "
>   },
>   {
>     "type": "filters.reprojection",
>     "in_srs": "EPSG:6783+5703",
>     "out_srs": "COMPD_CS[\"NAD83(CORS96) / UTM Zone 10N + NAVD88
> height\",PROJCS[\"NAD83(CORS96) / UTM Zone
> 10N\",GEOGCS[\"NAD83(CORS96)\",DATUM[\"NAD83_Continuously_Operating_Reference_Station_1996\",SPHEROID[\"GRS
> 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],AUTHORITY[\"EPSG\",\"1133\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"6782\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-123],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]],VERT_CS[\"NAVD88
> height\",VERT_DATUM[\"North American Vertical Datum
> 1988\",2005],UNIT[\"metre\",1],AXIS[\"Gravity-related
> height\",UP],AUTHORITY[\"EPSG\",\"5703\"]]]"
>   },
>   {
>     "type": "writers.copc",
>     "pipeline": true,
>     "forward": "header, vlr",
>     "offset_x": "auto",
>     "offset_y": "auto",
>     "offset_z": "auto",
>     "extra_dims": "all",
>     "filename": "pipeline10.copc.laz"
>   }
> ]
>
> If I switch the output srs to be "EPSG:6339+5703", I get no errors (6339
> is UTM zone 10 for NAD83(2011)), though I don't think it actually shifted
> from CORS96 to 2011. GDAL osr.SpatialReference doesn't dislike the CORS96
> utm 10 wkt, but it throws an exception if I try to AutoIndentifyEPSG().
>
> Is this the intended behavior or am I doing something wrong? I'm guessing
> it's related to the lack of an EPSG code, but perhaps I've gone down the
> wrong path.
>
> Note that the input file in the example uses EPSG:6782, but I simplified
> the pipeline by removing the geoid application part.
>
> Thanks for any pointers.
>
> Kirk Waters, PhD
> NOAA Office for Coastal Management
> Applied Sciences Program
> coast.noaa.gov/digitalcoast
>
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20260324/e8dc208f/attachment-0001.htm>

From andrew.bell.ia at gmail.com  Tue Mar 24 07:39:26 2026
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Tue, 24 Mar 2026 10:39:26 -0400
Subject: [pdal] Writers.copc changes global encoding
In-Reply-To: <021d69a774f7b34b1470b4d2e7579216@latuviitta.fi>
References: <CAGZyQoO97-2EPsJGQt+-JA2WVVCWTvYjnkQp=_hDPCp+6eBGEA@mail.gmail.com>
 <CACJ51z0MY=Zy_cMmb0o0Au4Xm0ZVTa2s7GW8esV2uGfb32gN4Q@mail.gmail.com>
 <e907e0d4c02283b6f201dcf831283752@latuviitta.fi>
 <CACJ51z05+Rjk0TH8Zxf9ZS4b+UiLgAb_W9YmhNJvhHVN-EsbiQ@mail.gmail.com>
 <e6d0e6169b0238debe341b375f565f9c@latuviitta.fi>
 <021d69a774f7b34b1470b4d2e7579216@latuviitta.fi>
Message-ID: <CACJ51z0weDAgeQ8T7c29pb74ja1yKy3AkUB=aqx0HyEuu7=Atg@mail.gmail.com>

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>

From howard at hobu.co  Tue Mar 24 10:27:24 2026
From: howard at hobu.co (Howard Butler)
Date: Tue, 24 Mar 2026 12:27:24 -0500
Subject: [pdal] Writers.copc changes global encoding
In-Reply-To: <e907e0d4c02283b6f201dcf831283752@latuviitta.fi>
References: <CAGZyQoO97-2EPsJGQt+-JA2WVVCWTvYjnkQp=_hDPCp+6eBGEA@mail.gmail.com>
 <CACJ51z0MY=Zy_cMmb0o0Au4Xm0ZVTa2s7GW8esV2uGfb32gN4Q@mail.gmail.com>
 <e907e0d4c02283b6f201dcf831283752@latuviitta.fi>
Message-ID: <F868C624-31A9-4B17-9BBA-DC716FDCB933@hobu.co>



> On Mar 23, 2026, at 2:41?PM, Jukka Rahkonen via pdal <pdal at lists.osgeo.org> wrote:
> 
> The error disappears if I add "forward":"all" into the pipeline but shouldn't the global_encoding value remain the same even without?


It has been PDAL's policy to refuse to guess. It makes sense that the modification of a single file would also bring along all of the attributes of things like global_encoding, but it becomes sticky if the user were reading multiple files at one time. PDAL would have to guess in that situation. forward=all is the way to tell PDAL to pull along the commonly expected things like global_encoding, or a more common sticking point, scale/offset factors.

> 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 

You'll need to add --writers.copc.extra_dims="all" or --writers.las.extra_dims="all" to make sure the extra attributes are copied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20260324/a2feacf7/attachment.htm>