possible to set crs of las files?

[wiesehahn]

For some reason the CRS in the laz files I am working with is not set properly by the provider, is there any way to define it with lasR? Or do I have to to it in advance with e.g. lidR (projection(las) <- 25832) or lastools?

[Jean-Romain]

There is currently no tool for that. This is in my todo list with a low priority. It is not hard to add so I may implement that on spare time. The real difficulty is to determine the behavior we are expecting. What would be the behavior of:

reader_las() + rasterize() + set_crs() + local_maximum()

If you read it as a pipeline then the raster has no crs or an incorrect crs and the vector have the correct crs. This makes sense if you consider the pipeline as a flow (which is correct).

But does it really makes sense? What would be the purpose? Should we rather expect set_crs() to apply globally to the entire pipeline, no matter its position in the pipeline?

Using reader_las() + set_crs() + rasterize() + local_maximum() is not ambiguous but the first example is ambiguous. I did not settle the question. This is why the feature is not implemented yet.

[wiesehahn]

I would exactly expect the above mentioned behavior and would be totally fine with it, however you might be right that it could be confusing to some.

This touches another question I had, is a pipeline always considered as a flow? In this case it would look more familar to me if the pipeline would be written in a piped way, not sure if this makes sense though.

Something like:

f |>
  reader_las() |>
  set_crs() |>
  rasterize() |>
  local_maximum()

[Jean-Romain]

I would exactly expect the above mentioned behavior and would be totally fine with it, however you might be right that it could be confusing to some.

I started looking at the code and this option is likely the simplest. Yet not simple. It require several internal change but this is likely what I'll do.

Something like:

What you are suggesting totally makes sense and corresponds to the syntax I would have preferred. However, I'm not sure if it is reaaly possible. AFAIK |> is an operator of the language and has a fixed meaning. f |> reader_las() |> set_crs() corresponds to set_crs(reader_las(f))). This means that each stage should have a pipeline as first argument

rasterize = function(pipeline, res, operators, filter, ofile)
{
}

It was not designed this way because I wanted to be able to write stuff like

del = triangulate()
dtm = rasterize(del)
norm = transform_with(del)
pipeline = del + dtm + norm

Your suggestion, while more elegant, does not offer as much flexibility than mine and I can't see how it would be possible to write pipeline = del |> dtm |> norm without overwriting the |> operator.

[wiesehahn]

ah yes I see, in the end its just syntax and if it works it works as it is :)

[Jean-Romain]

The version 0.5.0 in the devel branch has a new stage set_crs(). The following example demonstrates how it works but is useless. set_crs() should rather appear only once at the beginning after reader_las()

f <- system.file("extdata", "Topography.las", package="lasR")
pipeline <- reader_las() + rasterize(20, "count") + set_crs(2044) + local_maximum(5)  + set_crs(2004) + write_las()
ans = exec(pipeline, on = f)

Be careful, the devel branch is unstable. The new capacity to abort a computation has some unfixed troubles with the stages that call a user-defined R function (rasterize(myfunction(Z)), callback()) in parallel.

[wiesehahn]

Thanks.
The same bug as in #31 applies here. Probably the fix is not implemented in devel branch?!

With wildcard it fails

f <- system.file("extdata", "Topography.las", package="lasR")
pipeline <- reader_las()  + set_crs(2044) + local_maximum(5, ofile=  "*_ttops.geojson")
ans = exec(pipeline, on = f)

while this succeeds

f <- system.file("extdata", "Topography.las", package="lasR")
pipeline <- reader_las()  + set_crs(2044) + local_maximum(5, ofile=  "ttops.geojson")
ans = exec(pipeline, on = f)

[Jean-Romain]

I merged the fixes from the master branch in devel yesterday night but forgot to push the changes. So you may indeed have a non patched devel version. This should be fixed now.

[wiesehahn]

Assign a CRS in the pipeline. This stage does not reproject the data. It assigns a CRS.

So this should be pretty quick. I am wondering, why is it then that there is such a long processing time in the following case?

f <- "input.laz"

benchmark <- function(pipeline, data){
  start_time <- Sys.time()
  
  out <- lasR::exec(pipeline, on = data)
  
  end_time <- Sys.time()
  print(end_time - start_time)
  
  return(out)
}

ans <- benchmark(lasR::set_crs(25832) + lasR::write_vpc(tempfile(fileext = ".vpc")), data = f)
#> Time difference of 1.879164 mins
ans <- benchmark(lasR::write_vpc(tempfile(fileext = ".vpc")), data = f)
#> Time difference of 0.739675 secs

^{Created on 2024-05-15 with reprex v2.1.0}

[Jean-Romain]

Both are taking < 0.05 sec on my computer. So what is surprising me here is the 0.7 secs. However the first time you execute exec in a fresh R session it takes > 1.5 seconds. This is because of the terra package that takes 1.5 seconds to loads (see rspatial/terra#1440)

You may wonder what terra is doing here? Nothing actually but exec preloads terra::rast() and sf::st_read() in order to be able read back your results. Here your result is not a raster but the function terra::rast is preloaded anyway in order to read a raster is there is any.

So what takes 1.5 second is not the pipeline execution but the line rreader <- if (system.file(package='terra') != "") terra::rast. Clearly there is no plan to fix this in terra so I need to find a workaround myself for pipelines without raster.

If you run your benchmark a second time, terra will be already loaded and the benchmark will correspond to the actual execution of the pipeline and should take < 1 second.

Also with exec(..., noread = T) you can disable the reading of your files with sf and terra and thus you can benchmark the pure execution of the pipeline.

Btw, I become aware that the vpc file could be read with sf by default at the end of exec. I will add the feature.

[wiesehahn]

I am not sure you got it correct. I would not wonder if it takes longer than a second with set_crs in the pipeline, but it takes almost 2 minutes.

[Jean-Romain]

Indeed, the units are minutes... my bad. Ok, this one is surprising. Please report a dedicated issue. It is a problem with all your files? This specific file? Operating system? How many files? Does it run faster the second time? I was not able to reproduce so I need the maximum information you can give me.