search

r-lidar / lidR

Airborne LiDAR data manipulation and visualisation for forestry application
https://CRAN.R-project.org/package=lidR
GNU General Public License v3.0
604 stars 131 forks source link

Error assignment of an object of class “logical” is not valid using readLAS in 3.2.0 #485

Closed arojas314 closed 3 years ago

arojas314 commented 3 years ago

Hello,

I have an issue where i am trying to read a .LAS file using readLAS() function, but I am receiving an error. I am using a windows x64 machine.

My code:

library(sp)
library(raster)
library(lidR)

LASfile <- ("./data/teak_data/lidarAOI.las")
las <- readLAS(LASfile, select = "xyzr", filter = "-drop_z_below 0")

Error message:

#> Error in (function (cl, name, valueClass)  : 
#>   assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE

Thanks, Alex

Jean-Romain commented 3 years ago

I need the file to reproduce

arojas314 commented 3 years ago

Here you go. Thanks for the quick response JR.

lidarAOI.zip

Jean-Romain commented 3 years ago

It is perfectly read on my machine

library(lidR)
readLAS("lidarAOI.las")
#> class        : LAS (v1.3 format 3)
#> memory       : 37.2 Mb 
#> extent       : 320643.5, 321000, 4096591, 4097000 (xmin, xmax, ymin, ymax)
#> coord. ref.  : WGS 84 / UTM zone 11N 
#> area         : 87275.38 m²
#> points       : 424.1 thousand points
#> density      : 4.86 points/m²

Which version of lidR are you using? which version of rlas? R? Please show the output of readLASheader("lidarAOI.las")? Which operating system are you using? Thanks

arojas314 commented 3 years ago

R and package info

r version: 4.1.1 rStudio version: 2021.09.0 Build 35 lidR version: 3.2.1 rlas: 1.5.0

readLASheader output

readLASheader("lidarAOI.las")

File signature:           LASFÓ 
File source ID:           211 
Global encoding:
 - GPS Time Type: GPS Week Time 
 - Synthetic Return Numbers: no 
 - Well Know Text: CRS is GeoTIFF 
 - Aggregate Model: false 
Project ID - GUID:        00000000-0000-0000-0000-000000000000 
Version:                  1.3
System identifier:        WhiteboxTools by John Lindsay   WhiteboxTools                   åë 
Generating software:      WhiteboxTools                   åë 
File creation d/y:        285/2021
header size:              235 
Offset to point data:     330 
Num. var. length record:  1 
Point data format:        3 
Point data record length: 34 
Num. of point records:    424122 
Num. of points by return: 284380 107546 28507 3689 0 
Scale factor X Y Z:       0.01 0.01 0.01 
Offset X Y Z:             3e+05 4e+06 0 
min X Y Z:                320643.5 4096591 2134.34 
max X Y Z:                321000 4097000 2195.4 
Variable Length Records (VLR):
   Variable Length Record 1 of 1 
       Description:  
       Tags:
          Key 1024 value 1 
          Key 1025 value 2 
          Key 3072 value 32611 
          Key 4099 value 9001 
Extended Variable Length Records (EVLR):  void

Operating system information

Windows 10 home

image

Jean-Romain commented 3 years ago

Tested on windows and everything was ok. I suggest to reinstall lidR.

arojas314 commented 3 years ago

It seems the issue was that I had conflicting packages (and/or global settings) from my old Rstudio and R install. A complete uninstall of R, Rstudio, and Rtools, as well as removing temporary files and folders in the users directory, should fix the issue. Here is a good answer on stackexchange describing how to delete R and all associated files: https://stackoverflow.com/questions/55204017/how-to-uninstall-r-and-rstudio-with-all-packages-settings-and-everything-else

antoniobelchiorferraz commented 3 years ago

I have the exact same issue both on Mac and windows 

Error in (function (cl, name, valueClass)  : 
  assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE
antoniobelchiorferraz commented 3 years ago

it is not working after reinstalling R, Rstudio and Rtools on windows 10

lidar<-readLAS("C:/Users/..../Downloads/Kompia_Cloud_P2_buffer_10m.laz")
#> Error in (function (cl, name, valueClass)  : 
#>   assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE
#>  In addition: Warning messages:
#>  1: Invalid data: 27 points with a return number equal to 0 found. 
#>  2: Invalid data: 27 points with a number of returns equal to 0 found.
arojas314 commented 3 years ago

@antoniobelchiorferraz

Follow this link for a complete uninstall (on windows): https://stackoverflow.com/questions/55204017/how-to-uninstall-r-and-rstudio-with-all-packages-settings-and-everything-else

Quick review from that link: Make sure after you uninstall, to remove the directories for R and Rstudio in users Document directory: C:\Users\%USERNAME%\Documents\R and C:\Users\%USERNAME%\Documents\Rstudio

Also make sure to remove the directories for R and Rstudio in this directory: C:\Users\%USERNAME%\AppData\Local

If you don't remove those directories after uninstall, the previous dependencies are still saved. So make sure to do so.

After everything is uninstalled and you cleared those directories, then go ahead and reinstall in this order:

After you reinstalled, start by installing lidR through Rstudio, which will download all the necessary packages.

Then test by reading in a lidar file.

library(lidR)
lidar<-readLAS("C:/Users/..../Downloads/Kompia_Cloud_P2_buffer_10m.laz")
antoniobelchiorferraz commented 3 years ago

@arojas314

I follow that procedure twice make sure and, yet, does not work for me:

Error in (function (cl, name, valueClass) : assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE

antoniobelchiorferraz commented 3 years ago

@Jean-Romain

and it gives the very same error on both MAC and windows after reinstalling R, Studio and Rtools (and cleaning the related files carefully)

rror in (function (cl, name, valueClass) : assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE

candelas762 commented 3 years ago

I have the same error. Followed @arojas314 suggestion but the problem persists. It also fails when trying to read as a catalog. The error when reading any LAS/LAZ file is: 

LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
ctg = readLAScatalog(LASfile)
#>  Error in sp::SpatialPolygons(pgeom, proj4string = crs) : 
#>    is(proj4string, "CRS") is not TRUE
arojas314 commented 3 years ago

@antoniobelchiorferraz

Check that GDAL or PROJ is already installed on your system, and if so, remove the paths from your environment variables. Also, check your paths to see if you have Cygwin. If so, remove that also.

antoniobelchiorferraz commented 3 years ago

@Jean-Romain, will do. But what is exactly the source of the issue? I just test "lidR 3.1.4" in my personal MAC and it works perfectly as opposed to my work MAC with "lidR 3.2.1".

Is there any work around for that using "lidR 3.2.1"?

for instance by using rlas to read the .las file :

p = rlas::read.las("hen_faes_plot3_lidar.laz", filter = "-keep_random_fraction 0.01")
h = rlas::read.lasheader("hen_faes_plot3_lidar.laz")

and do some additional procedure to get around the error and build the lidar file in rlas by bringing together p and h ?

arojas314 commented 3 years ago

@antoniobelchiorferraz

I am starting a new issue because you are exactly right, we tested 3.2.1 across multiple windows and mac machines to no avail. We all get the same error. But when we installed the 3.1.4 version, it works fine.

To install lidR 3.1.4:

require(devtools)
install_version("lidR", version = "3.1.4", repos = "http://cran.us.r-project.org")
Jean-Romain commented 3 years ago

Ok I think I know what might be the problem. The only difference that might explain your trouble is the fact that 3.2.0 no longer uses rgdal that will be retired in 2024. It now uses sf only. Please report:

   GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H           PROJ 
 "3.9.0"        "3.2.1"        "7.2.1"         "true"         "true"        "7.2.1"
arojas314 commented 3 years ago

@Jean-Romain

antoniobelchiorferraz commented 3 years ago

note that I'm reporting you results from my MAC, not Windows (I can do it later if necessary)

1- I've tried a few files and get the error message for all of them (see below readLASheader(file.las) for two examples)

2- sf package version (me 1.0-3)

3- sf::sf_extSoftVersion()

          GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H           PROJ 
       "3.8.1"        "3.2.1"        "7.2.1"         "true"         "true"        "7.2.1"

1a) 

readLASheader("/Users/..../plot3.laz")
File signature:           LASF 
File source ID:           0 
Global encoding:
 - GPS Time Type: GPS Week Time 
 - Synthetic Return Numbers: no 
 - Well Know Text: CRS is GeoTIFF 
 - Aggregate Model: false 
Project ID - GUID:        00000000-0000-0000-0000-000000000000 
Version:                  1.1
System identifier:        LAStools (c) by rapidlasso GmbH 
Generating software:      lasmerge (version 150701) 
File creation d/y:        154/2018
header size:              227 
Offset to point data:     399 
Num. var. length record:  2 
Point data format:        1 
Point data record length: 28 
Num. of point records:    88980 
Num. of points by return: 65329 19578 3642 402 28 
Scale factor X Y Z:       0.01 0.01 0.01 
Offset X Y Z:             202021 2027314 0 
min X Y Z:                202275.6 2028313 354.98 
max X Y Z:                202325.6 2028363 397.55 
Variable Length Records (VLR):
   Variable Length Record 1 of 2 
       Description: GeoKeyDirectoryTag 
       Tags:
          Key 33922 value 0 
          Key 1024 value 1 
          Key 1025 value 1 
          Key 2052 value 9001 
          Key 2054 value 9102 
          Key 3072 value 32620 
   Variable Length Record 2 of 2 
       Description: GeoKeyDoubleParamsTag 
       data:                 0 
Extended Variable Length Records (EVLR):  void

1b)

> readLASheader(i)
WARNING: no payload for LASF_Projection VLR with record_id 34736.
File signature:           LASF>Q 
File source ID:           20798 
Global encoding:
 - GPS Time Type: GPS Week Time 
 - Synthetic Return Numbers: no 
 - Well Know Text: CRS is GeoTIFF 
 - Aggregate Model: false 
Project ID - GUID:        00000000-0000-0000-0000-000000000000 
Version:                  1.2
System identifier:        LAStools (c) by rapidlasso GmbH 
Generating software:      lasmerge (version 201207) 
File creation d/y:        263/2021
header size:              227 
Offset to point data:     494 
Num. var. length record:  3 
Point data format:        3 
Point data record length: 34 
Num. of point records:    232841235 
Num. of points by return: 180175772 45814385 6364625 467522 18537 
Scale factor X Y Z:       1.37172e-06 8.64969e-07 8.7014e-08 
Offset X Y Z:             258656 392845 661.282 
min X Y Z:                258116.9 391655.4 661.282 
max X Y Z:                260139.7 394033.8 771.49 
Variable Length Records (VLR):
   Variable Length Record 1 of 3 
       Description: GeoTiff GeoKeyDirectoryTag 
       Tags:
          Key 1024 value 1 
          Key 1025 value 1 
          Key 1026 value 0 
          Key 2049 value 33 
          Key 2054 value 9102 
          Key 3072 value 32633 
          Key 3076 value 9001 
   Variable Length Record 2 of 3 
       Description: GeoTiff GeoDoubleParamsTag
Jean-Romain commented 3 years ago

Ok good! Not really actually but thank you anyway. Please show me

LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
#> CRS arguments:
#> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
antoniobelchiorferraz commented 3 years ago

Funny: 

LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
#> [1] NA
arojas314 commented 3 years ago

@antoniobelchiorferraz

Could you show the message after you load lidR using library(lidR)?

antoniobelchiorferraz commented 3 years ago

that's another funny one. I've been receiving different messages lately, but here's the message since this problem started:

require(lidR)
Loading required package: lidR
Loading required package: raster
Loading required package: sp
lidR 3.2.1 using 1 threads. Help on <gis.stackexchange.com>. Bug report on <github.com/Jean-Romain/lidR>.
Warning message:
multiple methods tables found for ‘area’
arojas314 commented 3 years ago

I receive the same message when loading lidR version 3.2.1, but not when loading the 3.1.4

Warning message:
multiple methods tables found for ‘area’
Jean-Romain commented 3 years ago

Good we caught it, we got NA as expected. Now lets try to figure out why. Show me

epsg = epsg(header)
epsg
#> [1] 26917
lidR:::epsg2CRS(epsg)
#> CRS arguments:
#> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs 
crs = sf::st_crs(paste0("EPSG:", epsg))
crs
#> PROJCRS["NAD83 / UTM zone 17N" [...]
as(crs, "CRS")
#> CRS arguments:
#> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
antoniobelchiorferraz commented 3 years ago

epsg = epsg(header) Error in h(simpleError(msg, call)) : error in evaluating the argument 'object' in selecting a method for function 'epsg': object 'header' not found epsg standardGeneric for "epsg" defined from package "lidR"

function (object, ...) standardGeneric("epsg") <bytecode: 0x7faf22306f38> <environment: 0x7faf222f6078> Methods may be defined for arguments: object Use showMethods(epsg) for currently available ones.

lidR:::epsg2CRS(epsg) CRS arguments: NA crs = sf::st_crs(paste0("EPSG:", epsg)) Error in as.vector(x, "character") : cannot coerce type 'closure' to vector of type 'character' crs standardGeneric for "crs" defined from package "terra"

function (x, ...) standardGeneric("crs") <bytecode: 0x7faee704d160> <environment: 0x7faee7040600> Methods may be defined for arguments: x Use showMethods(crs) for currently available ones.

as(crs, "CRS") Error in as(crs, "CRS") : no method or default for coercing “standardGeneric” to “CRS”

Jean-Romain commented 3 years ago

Please help me on your side too... header was defined in the previous test...

LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
epsg = epsg(header)
epsg
#> [1] 26917
lidR:::epsg2CRS(epsg)
#> CRS arguments:
#> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs 
crs = sf::st_crs(paste0("EPSG:", epsg))
crs
#> PROJCRS["NAD83 / UTM zone 17N" [...]
as(crs, "CRS")
#> CRS arguments:
#> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
arojas314 commented 3 years ago

@Jean-Romain

header <- readLASheader(lasfile)

epsg <- epsg(header)
epsg
#> [1] 32611

lidR:::epsg2CRS(epsg)
#> CRS arguments:
#> +proj=utm +zone=11 +datum=WGS84 +units=m +no_defs 

crs <- sf::st_crs(paste0("EPSG:", epsg))
crs
Coordinate Reference System:
  User input: EPSG:32611 
  wkt:
PROJCRS["WGS 84 / UTM zone 11N",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["UTM zone 11N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-117,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Engineering survey, topographic mapping."],
        AREA["Between 120°W and 114°W, northern hemisphere between equator and 84°N, onshore and offshore. Canada - Alberta; British Columbia (BC); Northwest Territories (NWT); Nunavut. Mexico. United States (USA)."],
        BBOX[0,-120,84,-114]],
    ID["EPSG",32611]]

as(crs, "CRS")
CRS arguments:
 +proj=utm +zone=11 +datum=WGS84 +units=m +no_defs
antoniobelchiorferraz commented 3 years ago 

> LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
> header = readLASheader(LASfile)
> epsg = epsg(header)
> epsg
[1] 26917
> #> [1] 26917
> lidR:::epsg2CRS(epsg)
CRS arguments:
 +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs 
> #> CRS arguments:
> #> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs 
> crs = sf::st_crs(paste0("EPSG:", epsg))
> crs
Coordinate Reference System:
  User input: EPSG:26917 
  wkt:
PROJCRS["NAD83 / UTM zone 17N",
    BASEGEOGCRS["NAD83",
        DATUM["North American Datum 1983",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4269]],
    CONVERSION["UTM zone 17N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-81,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Engineering survey, topographic mapping."],
        AREA["North America - between 84°W and 78°W - onshore and offshore. Canada - Nunavut; Ontario; Quebec. United States (USA) - Florida; Georgia; Kentucky; Maryland; Michigan; New York; North Carolina; Ohio; Pennsylvania; South Carolina; Tennessee; Virginia; West Virginia."],
        BBOX[23.81,-84,84,-78]],
    ID["EPSG",26917]]
> #> PROJCRS["NAD83 / UTM zone 17N" [...]
> as(crs, "CRS")
CRS arguments:
 +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs 
> #> CRS arguments:
> #> +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
``
Jean-Romain commented 3 years ago

Well, I do not understand. You ran, crs(header) and it failed, then you ran roughly the code of crs and it worked... Can you redo it in a reprex. Copy paste exactly that, and paste what will be copied automatically in your clipbord

reprex::reprex({
library(lidR)
LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
projection(header)
projection(header, FALSE)
epsg = epsg(header)
epsg
lidR:::epsg2CRS(epsg)
lidR:::epsg2CRS(epsg, TRUE)
crs = sf::st_crs(paste0("EPSG:", epsg))
crs$Name
as(crs, "CRS")
})
Jean-Romain commented 3 years ago

Ok guys I reproduced on Windows. I don't know why it worked last time, I updated few thing and now it does not work. I will be able to fix it. It looks like a clash in namespace. Very weird.

Windows

library(lidR)
#> Le chargement a nécessité le package : raster
#> Le chargement a nécessité le package : sp
#> Warning: tables de méthodes multiples trouvées pour 'area'
LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
#> [1] NA
projection(header)
#> [1] "+proj=utm +zone=17 +datum=NAD83 +units=m +no_defs"
projection(header, FALSE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
epsg = epsg(header)
lidR:::epsg2CRS(epsg)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
lidR:::epsg2CRS(epsg, TRUE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
crs = sf::st_crs(paste0("EPSG:", epsg))
crs$Name
#> [1] "NAD83 / UTM zone 17N"
as(crs, "CRS")
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
readLAS(LASfile)
#> Error in (function (cl, name, valueClass) : assignment of an object of class "logical" is not valid for @'proj4string' in an object of class "LAS"; is(value, "CRS") is not TRUE

Linux

library(lidR)
#> Le chargement a nécessité le package : raster
#> Le chargement a nécessité le package : sp
library(terra)
#> terra version 1.4.11
#> 
#> Attachement du package : 'terra'
#> Les objets suivants sont masqués depuis 'package:lidR':
#> 
#>     area, crs, crs<-
#> Les objets suivants sont masqués depuis 'package:raster':
#> 
#>     adjacent, animate, area, boundaries, buffer, cellFromRowCol,
#>     cellFromRowColCombine, cellFromXY, clamp, click, colFromCell,
#>     colFromX, cover, crop, crosstab, crs, crs<-, distance, erase,
#>     extend, extract, flip, focal, freq, geom, hasValues, init,
#>     inMemory, interpolate, mask, modal, mosaic, ncell, ncol<-, nrow<-,
#>     origin, origin<-, plotRGB, rasterize, readStart, readStop, rectify,
#>     res, res<-, resample, RGB, rotate, rowColFromCell, rowFromCell,
#>     rowFromY, setMinMax, setValues, shift, stretch, symdif, terrain,
#>     trim, values, values<-, writeRaster, writeStart, writeStop,
#>     writeValues, xFromCell, xFromCol, xmax, xmax<-, xmin, xmin<-, xres,
#>     xyFromCell, yFromCell, yFromRow, ymax, ymax<-, ymin, ymin<-, yres,
#>     zonal, zoom
LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
#> Error in (function (classes, fdef, mtable) : unable to find an inherited method for function 'crs' for signature '"LASheader"'
projection(header)
#> [1] "+proj=utm +zone=17 +datum=NAD83 +units=m +no_defs"
projection(header, FALSE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
epsg = epsg(header)
lidR:::epsg2CRS(epsg)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
lidR:::epsg2CRS(epsg, TRUE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
crs = sf::st_crs(paste0("EPSG:", epsg))
crs$Name
#> [1] "NAD83 / UTM zone 17N"
as(crs, "CRS")
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
readLAS(LASfile)
#> class        : LAS (v1.2 format 1)
#> memory       : 6.2 Mb 
#> extent       : 684766.4, 684993.3, 5017773, 5018007 (xmin, xmax, ymin, ymax)
#> coord. ref.  : NAD83 / UTM zone 17N 
#> area         : 53112.69 m²
#> points       : 81.6 thousand points
#> density      : 1.54 points/m²

Created on 2021-10-15 by the reprex package (v2.0.1)

Jean-Romain commented 3 years ago

I do not understand the problem, I changed a single line of code to bypass the error and every problems are gone including some that look completely unrelated... It does not make sense...

Please install 3.2.2 and tell me if it is fixed on your machine. Do not ask me what was the problem

remotes::install_github("Jean-Romain/lidR")

Windows

library(lidR)
#> Le chargement a nécessité le package : raster
#> Le chargement a nécessité le package : sp
LASfile <- system.file("extdata", "Megaplot.laz", package="lidR")
header = readLASheader(LASfile)
crs(header)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
projection(header)
#> [1] "+proj=utm +zone=17 +datum=NAD83 +units=m +no_defs"
projection(header, FALSE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
epsg = epsg(header)
lidR:::epsg2CRS(epsg)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
lidR:::epsg2CRS(epsg, TRUE)
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
crs = sf::st_crs(paste0("EPSG:", epsg))
crs$Name
#> [1] "NAD83 / UTM zone 17N"
as(crs, "CRS")
#> CRS arguments:
#>  +proj=utm +zone=17 +datum=NAD83 +units=m +no_defs
readLAS(LASfile)
#> class        : LAS (v1.2 format 1)
#> memory       : 6.2 Mb 
#> extent       : 684766.4, 684993.3, 5017773, 5018007 (xmin, xmax, ymin, ymax)
#> coord. ref.  : NAD83 / UTM zone 17N 
#> area         : 53112.69 m²
#> points       : 81.6 thousand points
#> density      : 1.54 points/m²

Created on 2021-10-15 by the reprex package (v2.0.1)

Jean-Romain commented 3 years ago

Considering that on my Windows machine 3.2.1 was binary by the CRAN and 3.2.2 is self compiled my best guess is an issue with CRAN binaries. You will test it and I will submit the fix to CRAN if it works for you. We will retry with CRAN binaries when they will be available.

Jean-Romain commented 3 years ago

I confirm it is not an issue with lidR 3.2.1 but with CRAN binaries

remotes::install_github("cran/lidR")    # works
install.packages("lidR")                # fails
install.packages("lidR", type="source") # works

I"ll release 3.2.2 with hope it will fix it by triggering a new build

antoniobelchiorferraz commented 3 years ago

After installing lidR using remotes::install_github("cran/lidR") it works on my Windows; however, on my OS X I get the error here below that, I believe, it has to do with my gcc rather than with R or lidR. This is strange because I have Xcodes installed and gcc up-to-date. I guess there is some paths I need to fix but I'm not sure how, which can delay my report to you:

ld: warning: directory not found for option '-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin18/8.2.0' ld: warning: directory not found for option '-L/usr/local/gfortran/lib' ld: library not found for -lgfortran clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [lidR.so] Error 1 ERROR: compilation failed for package ‘lidR’

Jean-Romain commented 3 years ago

This is an issue with your compiler. Can't help on Mac

ahmedshovon commented 3 years ago

I got the same message.

Error in (function (cl, name, valueClass) : assignment of an object of class “logical” is not valid for @‘proj4string’ in an object of class “LAS”; is(value, "CRS") is not TRUE

Jean-Romain commented 3 years ago

I made some tests this morning before to release 3.2.2 and version 3.2.1 from CRAN worked fine. The version 3.2.1 on CRAN for Windows R-release is a build from friday October 15th i.e. few hours only after my last test. It seems that the new binaries are not corrupted. Please try again on windows and confirm if it works.

On Mac OS however the build is still from October 5th.

I do not know yet if I'm releasing 3.2.2 to trigger a new build. I'm waiting for your feedback

candelas762 commented 3 years ago

I followed this message and re-installed 3.2.1 with "install.packages("lidR", type="source")" .

I confirm it is not an issue with lidR 3.2.1 but with CRAN binaries

remotes::install_github("cran/lidR")    # works
install.packages("lidR")                # fails
install.packages("lidR", type="source") # works

I"ll release 3.2.2 with hope it will fix it by triggering a new build

It has been working just fine. No errors so far reading any LAS or LAZ file.

Jean-Romain commented 3 years ago

See my message above. Can you try again install.packages("lidR")

ahmedshovon commented 3 years ago

Thanks. Its working perfectly now.

After installation the version is still 3.2.1 though.

Thanks again.

Jean-Romain commented 3 years ago

Because I did nothing. The CRAN rebuild the package friday after my last message (no causality at all, just random luck). The new binaries seem not being corrupted

Jean-Romain commented 3 years ago

I released 3.2.2. I hope this will fix the problem. Binaries should be available within a week

Jean-Romain commented 3 years ago

MacOS releases are available. Please confirm it works Windows release for R 4.0 will be available tomorrow I guess

antoniobelchiorferraz commented 3 years ago

Hi @Jean-Romain , it works on both MacOS and Windows 10. Thank you so much for your promptly and helpfull response.

cingularities commented 2 years ago

Hi, @Jean-Romain, when I run readLas in a loop, it causes a fatal error and aborts the program. Is there a way to avoid this?

for(fileName in NEONpoints2017){
#Bring point cloud into Rstudio

NEONpoints <- readLAS(fileName)

#Calculate vegetation height above the ground
NEON_DSM = normalize_height(NEONpoints, algorithm = knnidw(k = 12, p = 3), na.rm = TRUE)

#Remove points that are below 0
NEON_DSM_clean = filter_poi(NEON_DSM, Z < 45)

#plot(NEON_DSM_clean)

#Create canopy height model(raster) from the normalized canopy points
NEON_CHM = grid_canopy(NEON_DSM_clean, res = 0.5, p2r(subcircle = 0.3, na.fill = NULL))

#Export the Canopy Height Model to a .tif
writeRaster(NEON_CHM,   
            filename=paste("D:/projects/RaBET/NEON_ONAQ/NEON_lidar-point-cloud-line/",substr(fileName, 43, 55), "_2017_CHM"),
            format="GTiff",
            overwrite=TRUE)
}
Jean-Romain commented 2 years ago

Your question is not related to the content of this issue. Please open an issue with a reproducible example

mrascao92 commented 2 years ago

Hi, is this available in Portugal? I've been trying to find it at packages library but the only available version is lidR 3.2.1.

I released 3.2.2. I hope this will fix the problem. Binaries should be available within a week