[pdal] filters.reprojection with WKT and no EPSG

[Kirk Waters - NOAA Federal]

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>