No X, Y, Z in ctg

[apeacosh]

Hi, my normalized .las files contain x,y,z data, however when I load them into R with readLASCATALOG, I don't see any x,y, or z data. They are there because I can run stdmetrics function on the ctg, but cannot run a user defined pixel_metrics because there are no Z metric visible when using ctg@data$Z.

las_check(ctg[1:2,])

Checking headers consistency

• Checking file version consistency... ✓
• Checking scale consistency... ✓
• Checking offset consistency... ✓
• Checking point type consistency... ✓
• Checking VLR consistency... ✓
• Checking CRS consistency... ✓ Checking the headers
• Checking scale factor validity... ✓
• Checking Point Data Format ID validity... ✓ Checking preprocessing already done
• Checking negative outliers... ✓
• Checking normalization... yes Checking the geometry
• Checking overlapping tiles... ✓
• Checking point indexation... yes

ctg[1:2,] class : LAScatalog (v1.2 format 1) extent : 338500, 339000, 6003700, 6005000 (xmin, xmax, ymin, ymax) coord. ref. : NA area : 0.65 kunits² points : 5.16 million points density : 7.9 points/units² density : 4.7 pulses/units² num. files : 2

names(ctg) [1] "File.Signature"
[2] "File.Source.ID"
[3] "GUID"
[4] "Version.Major"
[5] "Version.Minor"
[6] "System.Identifier"
[7] "Generating.Software"
[8] "File.Creation.Day.of.Year"
[9] "File.Creation.Year"
[10] "Header.Size"
[11] "Offset.to.point.data"
[12] "Number.of.variable.length.records" [13] "Point.Data.Format.ID"
[14] "Point.Data.Record.Length"
[15] "Number.of.point.records"
[16] "X.scale.factor"
[17] "Y.scale.factor"
[18] "Z.scale.factor"
[19] "X.offset"
[20] "Y.offset"
[21] "Z.offset"
[22] "Max.X"
[23] "Min.X"
[24] "Max.Y"
[25] "Min.Y"
[26] "Max.Z"
[27] "Min.Z"
[28] "CRS"
[29] "Number.of.1st.return"
[30] "Number.of.2nd.return"
[31] "Number.of.3rd.return"
[32] "Number.of.4th.return"
[33] "Number.of.5th.return"
[34] "filename"
[35] "geometry"

summary(ctg[1:2,]) class : LAScatalog (v1.2 format 1) extent : 338500, 339000, 6003700, 6005000 (xmin, xmax, ymin, ymax) coord. ref. : NA area : 0.65 kunits² points : 5.16 million points density : 7.9 points/units² density : 4.7 pulses/units² num. files : 2 proc. opt. : buffer: 30 | chunk: 0 input opt. : select: * | filter: output opt. : in memory | w2w guaranteed | merging enabled drivers :

• Raster : format = GTiff NAflag = -999999
• stars : NA_value = -999999
• SpatRaster : overwrite = FALSE NAflag = -999999
• SpatVector : overwrite = FALSE
• LAS : no parameter
• Spatial : overwrite = FALSE
• sf : quiet = TRUE
• data.frame : no parameter

ctg[1:2,]@data$Max.Z [1] 41.613 32.211

I can provide reproducible example if needed if there isn't an easy resolution.

Thanks

[Jean-Romain]

I suggest you to read the documentation of LAScatalog

A LAScatalog object is a representation of a collection of las/laz files. A LAScatalog is a way to manage and batch process a lidar coverage. It allows the user to process a large area, or to selectively clip data from a large area without loading all the data into computer memory. A LAScatalog can be built with the function readLAScatalog.

Details A LAScatalog contains an sf object to store the geometry and metadata. It is extended with slots that contain processing options. In lidR, each function that supports a LAScatalog as input will respect these processing options. Internally, processing a catalog is almost always the same and relies on a few steps:

[...]

You can also read the book https://r-lidar.github.io/lidRbook/engine.html

[apeacosh]

Can you confirm that there should be a Z component acessible the ctg.

ie: ctg@data$Z returns the Z coordinates.

If not, then how would your pixel_metrics function work?

eg: hmean <- pixel_metrics(ctg_norm, ~mean(Z), 10)

I had no problems with any of this running lidR 3.2.2 or less. With the upgrade, nothing works. If there is new way that the Z and intensity etc, are being stores in sf versus sp/rgdal, can you clarify how?

Thanks

[Jean-Romain]

Can you confirm that there should be a Z component acessible the ctg.
ie: ctg@data$Z returns the Z coordinates.

No it does not. A LAScatalog does not load the data. The dataset is assumed to be too big to be loaded in memory

If not, then how would your pixel_metrics function work? eg: hmean <- pixel_metrics(ctg_norm, ~mean(Z), 10)

By loading sequentially small chunks of data and discarding the chunks once done

I had no problems with any of this running lidR 3.2.2 or less. With the upgrade, nothing works.

It does not work is not a question. If you think something does not work please report with a minimal reproducible example so I can understand what does not work, what is the code used and what is the context. lidR 4.0 is expected to be backward compatible especially for simple case like that.