Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LAS 1.4 #27

Closed
jfprieur opened this issue Dec 19, 2018 · 4 comments
Closed

LAS 1.4 #27

jfprieur opened this issue Dec 19, 2018 · 4 comments
Assignees
Labels
Enhancement Not actually a bug but a possible improvement

Comments

@jfprieur
Copy link

Hi Jean-Romain,

There is not much to be done (I think it is a liblas problem) but I thought you should be aware that i ran into some strange errors when I use LAS 1.4 formatted files. I tried doing the tiling process with this new data and one tile would be written in the directory, then it would be erased, then the new tile, then erased, etc.

When I converted the LAS to 1.2 format using las2las everything worked fine as usual. This is on lidR v2.

As I said, I have always had problems with 1.4 format files, I know in Python there is a library called laspy that addresses liblas shortcomings, do not know if there is such a package in R that we could try.

Just thought you should be aware(!) if you were not already in case you get questions. Thanks again for the great R package!

@Jean-Romain Jean-Romain self-assigned this Dec 19, 2018
@Jean-Romain
Copy link
Collaborator

Hi,

This bug is likely to come from the rlas package. lidR writes sequentially the retiled files but files with 0 points are automatically removed. The point is that I have never seen a LAS 1.4 file. I don't even know if it is supported properly. According to this issue I guess that rlas writes 0 points. Please give me a small (e.g. 400 by 400 m) LAS 1.4 file and I will study this case.

@Jean-Romain
Copy link
Collaborator

Well, after thinking more about it, if LAS 1.4 files are read (no even sure of that) this format cannot be fully supported yet. For example in the LAS 1.4 format the scan angle rank can be a decimal value. If rlas read the file it will read it as an integer anyway. Just an example.

@Jean-Romain Jean-Romain transferred this issue from r-lidar/lidR Jan 1, 2019
@Jean-Romain Jean-Romain added the Enhancement Not actually a bug but a possible improvement label Jan 1, 2019
@Jean-Romain
Copy link
Collaborator

rlas 1.3.0 has a better support of LAS 1.4. I'm not done yet but at least it should fix your issue.

devtools::install_github("Jean-Romain/rlas", ref = "devel")

To support LAS 1.4 as well as LAS <= 1.3 in a consistent way I introduced a minor incompatibility with lidR <= 2.0.0. So you must also install lidR 2.0.1

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

Also if lidR 2.0.1 is not buggy with LAS 1.4 the full support of LAS 1.4 will wait for lidR 2.1.0. For example rlas 1.3.0 can read the CRS of a LAS 1.4 file as a WKT string but lidR is not able to take advantage of such information to build a 'R compliant' CRS.

Jean-Romain added a commit that referenced this issue Jan 9, 2019
@Jean-Romain
Copy link
Collaborator

rlas 1.3.0 has an almost full support of LAS 1.4 and point formats 0,1,2,3,6,7,8

Read

  • Read the multisprectal information ScannerChannel of point format > 6
  • Read the OverlapFlag bit of point format > 6
  • Read the extended ReturnNumber and NumberOfReturns of point format > 6
  • Read the extended Classification of point format > 6
  • Read the extended ScanAngle of point format > 6
  • Read the WKT OGC CS information

Write

  • Write the multisprectal information ScannerChannel of point format > 6
  • Write the OverlapFlag bit of point format > 6
  • Write the extended ReturnNumber and NumberOfReturns of point format > 6
  • Write the extended Classification
  • Write the extended ScanAngle of point format > 6
  • Write the WKT OGC CS (missing write of WKT OGC MATH TRANSFORM)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Not actually a bug but a possible improvement
Projects
None yet
Development

No branches or pull requests

2 participants