Closed oers closed 9 months ago
Good suggestion.
Would this work for you? https://github.com/mreutegg/laszip4j/pull/101
The difference between getPoints() and points() might be confusing, but this feature would help greatly and looks good.
Thanks for your feedback. I also considered the option of changing the return type of getPoints()
to return CloseablePointIterable
. That change would be source but not binary compatible. If we want to keep existing code compatible without the need to recompile, then I don't see another way than introducing a new method. I'm curious how you would add try-with-resources support.
Your right. Changing an existing lib is much harder than just adapting ones one piece of work. I also considered creating a constructor that has only an InputStream as an argument. Then I could just create/close the InputStream myself, after aborting iterating.
close the InputStream myself, after aborting iterating
This is already possible with the static method LASReader.getPoints(InputStream).
I updated https://github.com/mreutegg/laszip4j/pull/101 by changing the new method name from LASReader.points()
to LASReader.getCloseablePoints()
. I think this is more consistent with the existing method and gives a hint what the difference is.
The new method will be available in laszip4j 0.16
Thank you!
In LASReader an internal LASreader is created. The only way to close this ready is by iterrating all over the file until readNext() returns null
I think it would be beneficial to offer a method close(), that would close the reader directly. In our case we have a very very large LAZ File and if something goes wrong we want to close the handle on the file directly and not read the file until its very end.