<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi</p>
<p>I haven't followed the discussions close enough. <br>
</p>
<p>Is this page up to date?</p>
<p><a
href="http://trac.osgeo.org/postgis/wiki/PostGIS3?action=history">http://trac.osgeo.org/postgis/wiki/PostGIS3</a></p>
<p><br>
</p>
<p>What ideas have been abandoned and what is getting real?</p>
<p><br>
</p>
<p>I am specifically thinking about the serialization. I think the
ideas in that wiki page about a generic header and differnt
underlying coordinate storages, is very interesting.</p>
<p>There is also a bullet point about coordinate precision. This
also came up in this thread:</p>
<p><a
href="https://lists.osgeo.org/pipermail/postgis-devel/2019-May/027895.html">https://lists.osgeo.org/pipermail/postgis-devel/2019-May/027895.html</a></p>
<p><br>
</p>
<p>With a coordinate storage that can gain from less precision we
get both more compact data and control over the precision of the
data.</p>
<p>If the user knows that the accuracy of the data set is only 1 dm
it should be a win win to not store a lot of random numbers after
the first decimal.</p>
<p><br>
</p>
<p>I guess I might be to late to the party, since it is not that
many months to release, so I am mostly asking for what the status
is.<br>
</p>
<p><br>
</p>
<p>As I have mentioned in some mails earlier I also have a crazy
idea. Since a lot of the PostGIS users use it more or less for
storage and to render a map from that storage it makes sense to
optimize for rendering.</p>
<p>In my TilelessMap-app I am now using this technique (will push
the new code to F-droid quite soon) :</p>
<p>The polygon geometries is stored as twkb with triangulation
information.</p>
<p>I have extended the twkb geometry and use one of the unused flags
to indicate that it includes triangels.</p>
<p>Then, after the coordinates it is a list of indexes into the
coordinates describing the triangels.</p>
<p>By ordering the triangles in that list and store the indexes as
delta values it is close to 3 byte storage per triangle also for
very big polygons.<br>
</p>
<p>Those twkb-geometries with triangles is very well suited for
GPU-rendering.</p>
<p>Whendecoding the twkb, I get 2 arrays.</p>
<p>First is a list of coordinates and second is an array of triangle
indexes. Those arrays is exactly what the GPU wants to draw
polygons.<br>
</p>
<p>So, in short what needs to be done to render those polygons in
openGL is:</p>
<p><br>
</p>
<p>load the arrays to the GPU:</p>
<p> glBufferData(GL_ARRAY_BUFFER, sizeof(GLfloat) *
number_of_coordinate_values, coordinate_array, GL_STATIC_DRAW);</p>
<p> glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(GLshort) *
number_of_index_values, index_array, GL_STATIC_DRAW);<br>
</p>
<p>draw the triangles:<br>
</p>
<p>glDrawElements(GL_TRIANGLES, n_vals,GL_UNSIGNED_SHORT,(GLvoid*)
index_offset);<br>
</p>
<p><br>
</p>
<p>colors and z-values and so on is sent to the gpu as separate
values and handled in the shader code.</p>
<p>To recalculate to screen pixels a Matrix is also needded that
gets pushed to the gpu also handled in the shader code.</p>
<p><br>
</p>
<p>The point is that a format like that is extremely efficient for
rendering. It can of course be stored also now in PostGIS as a
bytea. <br>
</p>
<p>But if we had that possibility as a inbuilt type it would be
easier for something like Qgis to take advantage from that.</p>
<p>As mentioned before, if the user is aware of the accuracy of the
data set it is a win win win.</p>
<p>1) Smaller storage</p>
<p>2) faster rendering</p>
<p>3) coordinates that don't lie about their accuracy</p>
<p><br>
</p>
<p><br>
</p>
<p>If this model of splitting header and coordiante format as
described in the wiki page gets real, maybe things like this can
be added between major releases?</p>
<p>That would mean that a geometry working in PostGIS 3.5 might not
work in 3.0. That is not a good thing.</p>
<p>But if the header includes enough information it is at least easy
to avoid a crash and handle things correct. In the above example
for instance, the added triangles wouldn't stop PostGIS from
reading the coordiante part of the geometry. But it doesn't
understand the triangle part. <br>
</p>
<p>I have most of the code for this, but I guess it is too close to
release for talking this through and get things tested properly.</p>
<p>But the idea to store data as a gpu wants it is appealing.</p>
<p><br>
</p>
<p><br>
</p>
<p>Thanks</p>
<p><br>
</p>
<p>Nicklas<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>