<div dir="ltr"><div><div><div>Hi Nicklas,<br><br></div>This is indeed a great idea, and will go on further on the step already done here [1] with PostGIS 2.2 backend. QGIS 2.14 now uses ST_RemoveRepeatedPoints as described by one of the optimisations we can use with PostGIS<br><br></div>As you said, we could only use this format for rendering purpose, and not for spatial analyses or writing back to the PostgreSQL server.<br><br><br></div><div>I do not personaly know how much work is needed to achieve this, but this would be a great step further to lower bandwich usage and improve performance.<br></div><div><div><br>Cheers<br>Michaël<br><br>[1] <a href="https://github.com/qgis/QGIS/pull/2410">https://github.com/qgis/QGIS/pull/2410</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-02 9:24 GMT+01:00 Nicklas Avén <span dir="ltr"><<a href="mailto:nicklas.aven@jordogskog.no" target="_blank">nicklas.aven@jordogskog.no</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo all<br>
<br>
I have seen this question raised before some time ago on QGIS list.<br>
That made me glad :-)<br>
<br>
But I think maybe time is more right now, since twkb is suppoerted in a<br>
released PostGIS version.<br>
<br>
For anyone not knowing what twkb is:<br>
TWKB is a geometry format with similarities to wkb, but uses compressen<br>
the same way as MapBox Vector Tiles.<br>
<br>
I started to work with this format maybe 4 years ago.<br>
I added encoding support in PostGIS trunk some time after PostGIS 2.1<br>
release.<br>
<br>
I will not tell the whole history here, but last spring, in 2015 the<br>
format went through quite a big face lift. Since CartoDB was interested<br>
in using the format between their database servers and rendering<br>
servers, Paul Ramsey looked into the format and did some great<br>
improvements. He wrote a blog post about the result for CartoDB<br>
<a href="http://blog.cartodb.com/smaller-faster/" rel="noreferrer" target="_blank">http://blog.cartodb.com/smaller-faster/</a><br>
<br>
Also Javier Santana at CartoDB should be mentioned here since he was<br>
part of the discussions.<br>
<br>
Then with PostGIS 2.2 we now have encoding and decoding of twkb in<br>
PostGIS.<br>
<br>
I have all the time thought that twkb should be a good fit for the<br>
communication between PostGIS and QGIS.<br>
<br>
There is some things to consider though.<br>
TWKB doesn't preserve the precision in the coordinates. Because of that<br>
it is not suitable for writing back to the db.<br>
<br>
But the increased size (often about 7 times) compared to wkb would give<br>
a real boost to QGIS. Especially Encoding and decoding is fast. For<br>
example, writing a table inside PostGIS to a new table like:<br>
CREATE TABLE foo AS<br>
SELECT ST_Binary(geom) FROM table1;<br>
<br>
is slower than encoding and writing as twkb<br>
CREATE TABLE foo AS<br>
SELECT ST_AsTWKB(geom) FROM table1;<br>
<br>
But, as mentioned, then decimals is removed.<br>
The encoder in PostGIS takes a second argument that defines how many<br>
decimals that should be included. Default is 0 for meter based<br>
projections and 6 or 5 (I don't remember) for 4326. The precision value<br>
can also be negative which results in reounded integer values, like -1<br>
means 10 meters precision (on meter based projections)<br>
<br>
So here is my suggestion how to handle things.<br>
<br>
As an option for people using PostGIS >= 2.2 as backend, they can switch<br>
to twkb as transportation format. When zoomed out QGIS asks PostGIS for<br>
0 or -1 decimals precision. When zooming in QGIS requests more<br>
precision. But meter precision is enough for quite deep zooming.<br>
<br>
So, the editing issue. When the user opens a layer for editing QGIS will<br>
have to switch to wkb format. If not the whole geoemtry that is edited<br>
will loose precision when sent back.<br>
<br>
It could be possible of course to edit and accept less precision. For<br>
GIS-professionals that know how accurate their data is, they know that<br>
storing 10 decimals is no gain. They could decide that their data set<br>
only have cm precision and work both ways with twkb with 2 decimals.<br>
<br>
The compression is worse with 2 decimals than 0 decimals of course, but<br>
still smaller than wkb. So one approach could be that there is an option<br>
to decide with what precision to edit and use twkb as return format too.<br>
<br>
<br>
But as a first step I think decoding at QGIS as a client is a big step<br>
forward.<br>
<br>
I don't have the skills to write this in C++ myself, but everything<br>
needed exists in C, both in PostGIS and in a small standalone library<br>
that I have been playing with <a href="https://github.com/nicklasaven/twkbC" rel="noreferrer" target="_blank">https://github.com/nicklasaven/twkbC</a>.<br>
<br>
But to make things as fast as possible the decoding should of course be<br>
done directly from twkb into QGIS internal format, with no other<br>
representations in between.<br>
<br>
So, if anyone is interested, I will do all that I can to help. But I<br>
don't think it would be much faster to get someone on board that knows<br>
the QGIS code base and know C++, than me trying to do things myself.<br>
<br>
So, what do you think?<br>
Could this be interesting?<br>
If so, what next? This shouldn't be a very big thing if we find a way to<br>
work.<br>
<br>
I guess if it is interesting it is a candidate for QGIS 3.0<br>
<br>
<br>
Best Regards<br>
<br>
Nicklas Avén<br>
<br>
<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br></div>