Closed gwlucastrig closed 7 years ago
The two classes you are referring to are just a thin facade in front of the original laszip library ported to Java. I think it is a design choice of the original code to provide access to the raw data and the convenience classes simply pass through the data.
Thanks. I will havey application code make the adjustment. Please let me know if things change. And thanks again for posting this valuable project
On Feb 11, 2017 8:29 AM, "Marcel Reutegger" notifications@github.com wrote:
The two classes you are referring to are just a thin facade in front of the original laszip library ported to Java. I think it is a design choice of the original code to provide access to the raw data and the convenience classes simply pass through the data.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mreutegg/laszip4j/issues/2#issuecomment-279143809, or mute the thread https://github.com/notifications/unsubscribe-auth/ASyR4UI11rmVTpbBkBOW0IDY9FvFGCcvks5rbbeggaJpZM4L9_ig .
Also, just to let you know, I have released a version of my lidar viewer application that uses the laszip4j library to load LAZ files. Your code works beautifully.
This is more a question than an issue report... When reading LASPoint data using the LASReader class, I noticed that the x/y/z points returned were not adjusted using the scale and offset values from the LAS/LAZ file header. I'm not sure whether this is a deliberate design choice or not, but I wanted to bring it to your attention. It does explain why the values I got when I accessed the Kanton of Zürich data were so large. Should I be making the adjustment in my application, or should this happen in the laszip4j API?