[pgpointcloud] RLE and SIGBITS heuristics

[Howard Butler]

> On Apr 17, 2015, at 7:38 AM, Rémi Cura <remi.cura at gmail.com> wrote:
> 
> Hey,
> 
> For instance in every Lidar point cloud, the order is paramount, because the sensing is structured (lines usually).

This is true for linear mode lidar systems, but not so much for focal plane/geiger or point clouds from coincident image processing. In those cases, the order doesn’t have much meaning and it is ok to reorder the points. 

> So ordering can give you neighbourhood relation for free.
> Also, ordering may be important when you want to improve your point cloud registration .
> I don't mean point cloud global geolocalisation, but each point localisation in the sensor reference system.
> Typically points are sensed in the sensor reference system, then knowing the sensor trajectory in WGS, you put the point in WGS (for instance).
> Sadly sensor trakectory is always false to a point. Correcting it allow to re-register the points and improve points precision.

It is unfortunate that most LiDAR collections do not come with the trajectory and IMU information. 

> Sorry my answer was a little cryptic. 
> 
> (I talk about LOD in [this presentation](https://github.com/Remi-C/Postgres_Day_2014_10_RemiC/raw/master/presentation/A%20PostgreSQL%20Server%20for%20Point%20Cloud%20Storage%20and%20Processing.pdf) , p49 and 50)

This is a great resource!

> 
> For ordering points I build an octree, then for each level of the octree (0 to N), I take the point closest to the center of the cell.
> This gives you at most 8^K points at the level K. 
> (here illustration in 2D on real data. Biggest point = most important point = lower Level point. )
> I don't build an octree in fact, because you can get what point goes in which cell simply by looking at the binary coordinates of the points (after offset and scale).
> 
> This is cool is the user read the whole level. 
> But you can do something better by allowing continuous-LOD.
> In this scenario the user can read only a part of a level, and we still want that he gets well spaced points.

Please check out http://iowalidar.com with a recent version of Chrome. We’re essentially doing as you described, though the backend is Greyhound+S3 rather that pgpointcloud. Iowa is rather boring and flat, and the Iowa LiDAR set is nearly 10 years old and not very dense, but it was a convenient set for us to work with. Connor Manning has developed the indexing portion, and Uday Verma continued the plas.io work to support fetching data at different LoD. Double click for recenter, and mousewheel for zoom. The data are compressed using laz-perf as I mentioned earlier, and sent to the browser to be decompressed in Javascript. Imagery is just Mapbox satellite+roads tiles, and the whole thing is in Web Mercator for convenience (it’s a browser, you want millimeter accuracy?!?!?).

All of this stuff should be open source shortly, but not in PDAL. The tree-building code is especially neat, because it supports parallel insertion.

Howard