You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenTopography is a repository that stores a large amount of CC-0 LiDAR point cloud data. Since OpenTopography is about to become a member node of DataONE (see DataONEorg/member-repos#15), this presents an opportunity to scale up portal visualization processing and display.
A good test of that capability might be to process a large dataset such as this Dangermond survey (edit: from 2019, published in 2022) into Cesium tiles for portal visualization. This would allow for both a benchmark test of efficiency processing a mid volume (65 GB or nearly 8 billion points) dataset as well as a test of true aerial rather than ground and low altitude data such as is represented in DRP, which the workflow was built to accommodate initially.
The text was updated successfully, but these errors were encountered:
@mbjones there is a way to determine whether a dataset is LAS or not. The SID of the Dangermond LAS dataset is OTLAS.042022.32611.1 whereas the vegetation-removed DEM version's SID is OTSDEM.042022.32611.1.
That's great. So, processing the Dangermond dataset and thinking about how to apply this more broadly would be a great side project when things are slow (🤯 ).
OpenTopography is a repository that stores a large amount of CC-0 LiDAR point cloud data. Since OpenTopography is about to become a member node of DataONE (see DataONEorg/member-repos#15), this presents an opportunity to scale up portal visualization processing and display.
A good test of that capability might be to process a large dataset such as this Dangermond survey (edit: from 2019, published in 2022) into Cesium tiles for portal visualization. This would allow for both a benchmark test of efficiency processing a mid volume (65 GB or nearly 8 billion points) dataset as well as a test of true aerial rather than ground and low altitude data such as is represented in DRP, which the workflow was built to accommodate initially.
The text was updated successfully, but these errors were encountered: