lasvdatum, epsg codes and proj geodetic database

[Wes Toews]

Hello and happy new year!

1) The lasvdatum tool is great. It takes an -epsg argument to be able to transform points back into geographic coordinates. Since the proj4 integration with las2las, is it (or will it be) possible to specify like a -proj_epsg code and use that mechanism for coordinate transformation? Just to ensure consistency.

2) Related, proj4 has published geodetic tiff grids (Geodetic TIFF grids (GTG) — PROJ 9.7.1 documentation) and a CDN (PROJ Datumgrid CDN) of these grids. lasvdatum currently uses GTX. Is it possible to upgrade to taking these tiffs? Probably constrained by VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL tag or the band description "geoid_undulation" or something. Converting from tif -> gtx is fine, but using GDAL, I sometimes needed to add -unscale -ot Float32 in order for the GTX to be correct (just the first thing I discovered, there are probably more issues). I'm sure there's a reason for GTX, so I guess I'm expecting to be corrected here.

Thanks!

[Jochen Rapidlasso]

Happy New Year to all LAStools users and friends!

About your questions: PROJ is only available at las2las64 right now. Using las2las64 with PROJ arguments means that you give away the conversion to PROJ. If you define a conversion where PROJ have to use a grid (or is configured that way) it should work with all kinds of grids PROJ is able to use. All this is done on PROJ side. If this does not work as you expect please define a small but complete sample and we will try to help.

Cheers,

Jochen @rapidlasso

[Wes]

Hi Jochen, thanks for your explanation, I think this is the right way to go. However could you humor me and try to transform into EPSG:3153 and a grid shift of any kind using vgridshift? I attached a little sample file. It's not clear to me how the behavior differs between say cct and lastools proj.

For example, these work as expected, using cct:

echo 300000 5000000 123 0 | cct +proj=pipeline +step +inv +proj=utm +zone=10 +ellps=GRS80 +step +proj=vgridshift +grids=/path/to/ca_nrc_CGG2013n83.tif +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80 +units=m

echo 300000 5000000 123 0 | cct +proj=pipeline +step +inv +proj=utm +zone=10 +ellps=GRS80 +step +proj=vgridshift +grids=/path/to/ca_nrc_CGG2013n83.tif +step +proj=utm +zone=10 +ellps=GRS80

however, using the same statements with various modifications I tried in las2las64 proj_string generate the following errors:

SERIOUS WARNING: The WKT representation could not be generated and could not be written to the output file header! It is therefore not possible to determine the CRS of the file.
ERROR: Failed to create PROJ object for the transformation. Currently, only transformations between different Coordinate Reference Systems (CRS) are supported. This means that the CRS information must be included in the input, such as in PROJ string, WKT, or PROJJSON. Pure Coordinate System (CS) operations are not supported at the moment.

but using proj_string arguments such as these all work, and the CRS for the last two is lifted from the input las file as expected.

"epsg:3157" "epsg:3153"

"epsg:3153"

"+proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80 +towgs84=-0.991,1.9072,0.5129,-1.25033e-07,-4.6785e-08,-5.6529e-08,0 +units=m +no_defs +type=crs"

If proj handles the transformation 100% why does the 'only transformations between different CRS' issue message exist, or am I doing something obviously wrong? Quite possibly I'm confused about something so I would value your clarification.

Thanks Jochen!
Wes

[Jochen Rapidlasso]

Hi Wes,

thanks for the detailed example.

 

The cct commands you provided use an explicit PROJ pipeline (+proj=pipeline +step ...), which represents a transformation object rather than a CRS definition. This works as expected in cct because it directly creates and executes the pipeline via proj_create().

 

In contrast, las2las currently operates in a CRS-to-CRS model, using CRS objects. Parameters like proj_string, proj_epsg, proj_wkt, and proj_json are interpreted as CRS definitions, not executable transformation pipelines. As a result, explicit pipeline steps such as vgridshift with a manually specified grid cannot be expressed or enforced through these interfaces.

 

This also explains the warning and error you get:

SERIOUS WARNING: The WKT representation could not be generated...
ERROR: Failed to create PROJ object for the transformation...

Internally, the PROJ C-API call proj_as_wkt(proj_ctx, proj_crs, ...) fails because it expects a CRS object. A pipeline does not have a WKT representation, and PROJ cannot serialize a transformation as a CRS. Consequently, proj_create_crs_to_crs_from_pj() also fails, because it requires proper CRS objects on both sides. EPSG- or CRS-based strings work because they define actual CRS objects, allowing PROJ to resolve transformations implicitly. Explicit pipeline control is outside the current scope of LAStools PROJ integration, which is why such pipelines cannot be mapped 1:1 to a proj_string.

We hope this helps you to understand the situation,

Cheers,

Jochen @rapidlasso

[Wes Toews]

Yes Jochen that is a clear explanation thank you. I guess I got too excited, but, lasvdatum should fill the gap in what I’m trying to do.

Thanks

Wes

--
Download LAStools at
https://rapidlasso.de
Manage your settings at
https://groups.google.com/g/lastools/membership
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lastools/77badc4e-0d3d-4743-a862-4b2fcadf0b97n%40googlegroups.com.