Writing support, error handling and simplifications

[oyhj1801]

Hi!

I realized I should probably have filed draft PR on my work on a writer and some other stuff.

Done:

• Simplification of reader, decompressor, las 0.9 dep, more tightly knit with las crate and removed viewer Update dependecy las #8
• I think I do proper error handling everywhere, but would like some feedback Add proper error handling #4

WIP:

• Writer

I have implemented a writer that writes copc files (not thoroughly tested) #7
BUT the writer does not write "good" files.
By that I mean that full resolution spatial queries are good, but limited resolution queries return bad results.
This is because the point distribution in a level does not represent the distribution of the entire cloud.
This means that viewing the file in a copc viewer will not look right.
I stopped working on the writer 3months ago as all I need for my current project are copc files with good full resolution queries.
I would like to make a proper writer when I find time, but don't know when that is.
Help is appreciated

[oyhj1801]

The approach I have taken with the writer is that I want it to keep as few points in memory at any one time as possible (this is a constraint I added due to my current project where I would like to do multiple files in parallel).

So I have made two node insertions strategies:

• Greedy, insert the current point in the highest level open node where the point is inside the node bounds
• Probabilistic, insert the current point in one of the open nodes where the point is inside the node bounds at random weighted by the number of points that level can hold.
  The probabilistic approach makes some assumptions to calculate the number of octree levels to open up from the start based on the number of points to be written (and that the lidar file cover a way bigger area in horizontal dimensions than in the vertical).

Both strategies writes a node to file as soon as it is filled up.
This is problematic as no corrections can be made based on point distribution or tiny leaf nodes.

I think a whole new writing strategy must be written and the constraint of not holding full nodes in memory must be scrapped.
But for now the writer does what I need, so I have not been able to justify using time the last months to try and correct it.

[pka]

Thanks for your work on copc-rs! I'm fine with merging a non-optimal writer implementation. The only nitpick is that bumping to version 1.0 is too early. So feel free to un-draft your PR, if it's working for your use case.