<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’ll start by describing what I have currently running inside of Cesium, as its probably the simplest (read: least technically sophisticated) approach amongst us.<div class=""><br class=""></div><div class="">(I’ll parameterize my approach along six dimensions; if others could follow this or a similar breakdown it might make it easier to discuss / compare / contrast).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(1) DATA SET - Determined via the URL prefix, e.g. <a href="http://www.example.com/points/serpentmound/" class="">http://www.example.com/points/serpentmound/</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(2) METADATA - A json file at the dataset URL root describes things including the tiling scheme, the bounding boxes of both the level-0 tile extents and the point cloud data, and the dimensions (name, datatype, min/mean/max).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(3) TREE STRUCTURE - Basic quadtree, where a rectangular node at level L reduces to 4 equally-sized nodes at level L+1. The node payload includes the point data itself plus a byte at the end that indicates which of the 4 children actually exists on disk; the root tile(s) are guaranteed to exist. </div><div class="">“Top-down” view only: that is, I use rectangles not cubes. The design is adapted straight from <a href="http://cesiumjs.org/data-and-assets/terrain/formats/heightmap-1.0.html" class="">http://cesiumjs.org/data-and-assets/terrain/formats/heightmap-1.0.html</a>.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(4) PAYLOAD - Each tile contains a set of points covering that tile’s spatial extent. The points are represented in raw form, in point order: X0, Y0, Z0, T0, X1, Y1, Z1, T1, etc. Data is stored little-endian in the datatype described in the JSON header.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(5) POINT SELECTION - All the points are contained in the leaf node tiles at level N. Each tile at level N-1 contains 1/4 of the points contained in the level N nodes. The “decimation” process currently used just naively takes every 4th point, but I would cal this an implementation detail: the tiling scheme does not mandate how many points should be in a tile or how they are chosen.</div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(6) COMMENTS, ASSUMPTIONS, PROBLEMS, ETC:</div><div class=""> - I’m aiming at the simplest approach that could reasonably work, with the least cost to the server to generate and the client to interpret.</div><div class=""> - I currently assume that level 0 has exactly two root tiles covering the whole globe, but I will generalize it to be able to have a single root tile for a given region.</div><div class=""> - I was using web sockets, but switched back to http because I’m (now) assuming that number of bytes in a tile is “reasonable”, i.e. doesn’t justify the need for sockets</div><div class=""> - No compression is used, although I’d like to gzip each tile. Just because.</div><div class=""> - Using a “las2tiles” approach to build the tiles, based on PDAL. Should probably make that code into a Real PDAL Driver at some point.</div><div class=""><br class=""></div><div class=""><br class=""><div class="">
-mpg<br class=""><br class=""><br class="">
</div>
<br class=""></div></div></body></html>