<div dir="ltr">Great to hear that ST_AsMVT is useful.<div><br></div><div>The other PostGIS capability that is useful for web spatial applications is the (recently enhanced) ST_AsGeoJSON.  This should also be gzipped over the wire.  So this suggests a modular gzip capability would be more useful.</div><div><br></div><div>If this isn't provided in Postgres in some way (now or in near term) perhaps we should just add a ST_Gzip function to PostGIS.</div><div><br></div><div>Out of curiosity, what platform do you use for your external gzipping layer?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 3, 2019 at 8:29 AM nyurik <<a href="mailto:yuriastrakhan@gmail.com">yuriastrakhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The amazing ST_AsMVT() has two common usage patterns:  copy resulting MVTs to<br>
a tile cache (e.g. .mbtiles file or a materialized view), or serve MVT to<br>
the users (direct SQL->browser approach).  Both patterns still require one<br>
additional data processing step -- gziping.<br>
<br>
Thus, rather than having a horizontally scalable db plus a simple IO-bound<br>
SQL->Web or a SQL->store process, one has to add a relatively CPU-intensive<br>
gzipping layer.  This is especially relevant if I try to create a PG table<br>
with the pre-generated tiles - I must use an external data compression<br>
process to retrieve a tile, gzip it, and store it back, instead of running a<br>
single query for copying all tiles.  My cursory look at the tile sizes<br>
indicate gzipping shrinks MVTs 50% to 300%.<br>
<br>
Note that a similar CPU-intensive step - creating MD5 tile hashes for a more<br>
efficient storage - can be easily done with PG's `md5()` function, whereas<br>
`gzip()` doesn't appear to exist.<br>
<br>
I would like to propose two possible solutions:<br>
* Implement ST_AsMVT(..., compress) parameter - NULL=no compression,<br>
0-9=compression level.<br>
   PROs:  adds just the required functionality to where it is needed (YAGNI<br>
principle), does not require ungzip yet (ST_AsMVT is a one way function<br>
without the corresponding MVT->Table method)<br>
   CONs: less generic (unusable for non-MVT usage)<br>
* Implement gzip() or ST_gzip()<br>
   PROs:  a more generic approach not tied to MVTs<br>
   CONs:  logically implies the need of ungzip(), requires PG community to<br>
agree this functionality is needed<br>
<br>
Thanks!<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://postgis.17.x6.nabble.com/PostGIS-Dev-f3570762.html" rel="noreferrer" target="_blank">http://postgis.17.x6.nabble.com/PostGIS-Dev-f3570762.html</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>