I am working on releasing a benchmark dataset for trees in RGB + Lidar and I'd like the format to match the most common use cases and packages. I had been intending on proving a tree index using the user_data column. Alot of preprocessing happens in python and i'm writing from laspy. I realized that user_data is clamped 0-255 (there are thousands of trees), meaning that trees do not have a unique index. I'm starting to write an extra dimension function

https://stackoverflow.com/questions/50815580/appending-an-index-to-laspy-file-las

but looking here, it looks like lidR is going to ignore those columns

https://cran.r-project.org/web/packages/lidR/vignettes/lidR-LAS-class.html

and i'll need users to do lasadddata anyways. Perhaps it would be best to just provide a csv lookup table based on x,y,z? With millions of points, will this be the best strategy? I'm worried about precision rounding among platforms. Thoughts welcome on how future users will best interact with extra dim data.