Closed apeacosh closed 1 year ago
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
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
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.
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
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 :
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