Jean-Romain

Thank you very much for this long and detailed answer. The good new is that my understanding of how `future` works is good. Your answer confirms some of my guesses...

Thanks for your reply. Testing the class of the current plan is already the first step of my parser. But the entire code is more complex as it also tries...

For a broader range of applications I'd say that the request consists in giving an option to return the attributes of the points that were tree apices. However I'm not...

For more information about LAS WKT see the format specification section 3.2 [here](http://www.asprs.org/wp-content/uploads/2019/07/LAS_1_4_r15.pdf). The specification states (among other) > For definition of WKT, we refer to Open Geospatial Consortium (OGC)...

I think this answers the question. There are also many LAS file in the wild that record non-existing epsg code so I'm not surprised.

@hobu the header contains ``` System identifier: NIIRS10 Generating software: GeoCue LAS Updater ```

@hobu FYI I retrieved the other file with the WKT mentioned by @rsbivand ``` System identifier: ALSXX Generating software: CloudPro1.2.4.106713 ```

> I would prioritize the unit tests before looking into performance. Of course > we could work on this together My knowledge about JS is limited to few scripts copy/pasted...

Ok for speed it is my fault. It a mistake I added I my R configuration and `g++` was not longer compiling with `-02`. One question solved.

For your information. Your version is 50 times faster when there are very few points (probably because of the overhead introduced by calling JavaScript in R via a V8 wrapper)...