<div dir="ltr"><div><div><div><div><div>Hey Oscar (and Peter), <br></div>great series of articles, the benchmark was really interesting !<br><br></div>I personally am adamantly against reordering the points for storage purpose, because the order can have a strong meaning (physical or theoretical).<br><br></div>For instance I re-ordered the points of my patch so that the points follows a LOD schema.<br></div>So reading more and more points gives a better and better approximation of the patch.<br></div><div>This gives free LOD facilities when all the patch have been re-ordered (free CPU wise, and no data duplication).<br></div><div><br></div><div>Now I have to admit that efficient storage and LOD are in conflict, because storing is about putting the similar points together somehow, and LOD is about the opposite (kind of sequential vs random access).<br></div><div>This has a strong impact, for instance reordering patches randomly will greatly increase patch storage size in pgpointcloud.<br></div><div>It is funny because for LOD I considered using an inverse morton curve (interleave X Y Z , then read is backward ! ).<br></div><div><br></div><div>I'm well aware that we could simply store the original order in an attribute, and so compression based on morton on XYZ might be transparent for the user.<br></div><div><br></div><div>Anyway, just to say that pgpointcloud is ultimately not about storing points, but easing point cloud usage in my opinion.<br></div><div><br></div><div>Cheers,<br></div><div>Rémi-C<br></div><div><br></div><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-17 11:02 GMT+02:00 Oscar Martinez Rubi <span dir="ltr"><<a href="mailto:o.martinezrubi@tudelft.nl" target="_blank">o.martinezrubi@tudelft.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
About the XYZ binding for better compression. In our research in the
NL escience center and TU Delft we have been thinking (not testing
yet though) about one possible approach for this.<br>
<br>
It is based on using space filling curves. So, once you have the
points that go in a block you could compute the morton/hilbert code
of the XYZ. Since all the points are close together such codes will
be extremely similar, so one could store only the increments which
could fit in many few bits. We have not tested or compared this with
any of the other compressions but we just wanted to share it with
you just in case you find it useful!<br>
<br>
An additional improvement would be to sort the points within the
blocks according to the morton code. Then, when doing crop/filter
operations in the blocks one can use the morton codes for the
queries similarly to what we presented in our papers with the flat
table (without blocks), I attach one of them (see section 5.2). In a
nutshell: You convert the query region into a set of quadtree/octree
nodes which can be also converted to morton code ranges (thanks to
relation between morton/hilbert curve and a quadtree/octree). You
scale down the ranges to increments (like you did when storing the
point of the block) and then you simply do range queries in sorted
data with a binary algorithm. In this way you avoid the
decompression of the morton code for most of the block. This
filtering is equivalent to a bbox filter so it still requires a
point in polygon check for some of the points.<br>
<br>
Kind Regards,<br>
<br>
Oscar.<div><div class="h5"><br>
<br>
<br>
<div>On 16-04-15 18:15, Rémi Cura wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div><span style="font-family:monospace,monospace">epic fail ! I
had avoided html just for you<br>
</span></div>
<div><span style="font-family:monospace,monospace"><br>
Dataset |subset size | compressing | decompressing |<br>
|(Million pts)|(Million pts/s)|(Million pts/s)|<br>
Lidar | 473.3 | 4,49 | 4,67 |<br>
</span></div>
<span style="font-family:monospace,monospace">21-atributes |
105.7 | 1,11 | 2,62 |<br>
</span>
<div>
<div><span style="font-family:monospace,monospace">Stereo
| 70 | 2,44 | 7,38 |<br>
<br>
</span></div>
<div><span style="font-family:monospace,monospace">Cheers<br>
</span></div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-04-16 17:42 GMT+02:00 Sandro
Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Apr 16, 2015 at 05:30:12PM +0200, Rémi
Cura wrote:<br>
> OUps<br>
><br>
> Dataset | subset size(Million pts) |
compressing (Million pts/s) |<br>
> decompressing (Million pts/s)<br>
> Lidar | 473.3 |
4,49<br>
> | __4,67__<br>
> 21 attributes | 105.7 |<br>
> 1,11 | 2,62<br>
> Stereo | 70 |
2,44<br>
> | 7,38<br>
<br>
</span>These tables aren't really readable here.<br>
Could you make sure to use a fixed-width font to write those
tables<br>
and to keep lines within 70 columns at most ?<br>
<br>
--strk;<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
pgpointcloud mailing list
<a href="mailto:pgpointcloud@lists.osgeo.org" target="_blank">pgpointcloud@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/pgpointcloud" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/pgpointcloud</a></pre>
</span></blockquote>
<br>
</div>
</blockquote></div><br></div>