Hello,
for a typical read-only LiDAR database that responds to user queries
that are square, rectangular or circular area-of-interest queries in
the XY plane you should include a comparison with LAStools in your
studies. Move the entire 80 GB of LiDAR (tiles?) either as
uncompressed LAS or as compressed LAZ into one folder and then run
either
lasindex -i folder\*.las -cores 4
or
lasindex -i folder\*.laz -cores 4
now you have a simple file-based read-only data base that can be queried with
las2las -i folder\*.las -merged ^
-inside 627980 5402870 628050 5403020 ^
-o result1.laz
las2las -i folder\*.laz -merged ^
-inside_tile 627750 5402750 500 ^
-o result1.laz
Or even better via a front-end like Hugo Ledoux from TU Delft did it:
http://3dsm.bk.tudelft.nl/matahn
who uses open-layer, a Python-based server (Flask) and PostGIS to
store the tiles' boundaries and all the metadata. If you have such a
setup then you can let PostGIS do the intersection of tile boundaries
with area-of-interest query and hand only a '-lof list_of_files.txt'
to las2las as input that contains a list of those LiDAR file names
that are actually overlapping the query area ...
For such applications the speed and simplicity in setup, the high
storage efficiency, the excellent performance, and the price (you can
use all open source components) make it an interesting "minimal effort
spatial database" to compare Oracle with as done in the aforementioned
article by Oscar Martinez and team.
Below three of his SPAR/ELMF presentation slides that highlight the
performance results for the simple database case I describe above.
Regards,
Martin @rapidlasso