[postgis-devel] About formats and PostGIS 3

[Nicklas Avén]

Hi

I haven't followed the discussions close enough.

Is this page up to date?

http://trac.osgeo.org/postgis/wiki/PostGIS3 
<http://trac.osgeo.org/postgis/wiki/PostGIS3?action=history>


What ideas have been abandoned and what is getting real?


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.

There is also a bullet point about coordinate precision. This also came 
up in this thread:

https://lists.osgeo.org/pipermail/postgis-devel/2019-May/027895.html


With a coordinate storage that can gain from less precision we get both 
more compact data and control over the precision of the data.

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.


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.


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.

In my TilelessMap-app I am now using this technique (will push the new 
code to F-droid quite soon) :

The polygon geometries is stored as twkb with triangulation information.

I have extended the twkb geometry and use one of the unused flags to 
indicate that it includes triangels.

Then, after the coordinates it is a list of indexes into the coordinates 
describing the triangels.

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.

Those twkb-geometries with triangles is very well suited for GPU-rendering.

Whendecoding the twkb, I get 2 arrays.

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.

So, in short what needs to be done to render those polygons in openGL is:


load the arrays to the GPU:

    glBufferData(GL_ARRAY_BUFFER, sizeof(GLfloat) * 
number_of_coordinate_values, coordinate_array, GL_STATIC_DRAW);

     glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(GLshort) * 
number_of_index_values, index_array, GL_STATIC_DRAW);

draw the triangles:

glDrawElements(GL_TRIANGLES, n_vals,GL_UNSIGNED_SHORT,(GLvoid*) 
index_offset);


colors and z-values and so on is sent to the gpu as separate values and 
handled in the shader code.

To recalculate to screen pixels a Matrix is also needded that gets 
pushed to the gpu also handled in the shader code.


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.

But if we had that possibility as a inbuilt type it would be easier for 
something like Qgis to take advantage from that.

As mentioned before, if the user is aware of the accuracy of the data 
set it is a win win win.

1) Smaller storage

2) faster rendering

3) coordinates that don't lie about their accuracy



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?

That would mean that a geometry working in PostGIS 3.5 might not work in 
3.0. That is not a good thing.

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.

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.

But the idea to store data as a gpu wants it is appealing.



Thanks


Nicklas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190508/1860ad43/attachment.html>