<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>
<div>Hi</div><div><br></div><div>You could take a look at the twkb format. There is encoder (ST_AsTWKB) and decoder (ST_GeomFromTWKB) in PostGIS since version 2.2. Twkb can be stored as bytea in the database. </div><div><br></div><div>HTH</div><div>Nicklas Avén</div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><div style="font-size:85%;color:#575757">Sent from my Samsung device</div></div><br><br>-------- Original message --------<br>From: Peter Devoy <peter@3xe.co.uk> <br>Date: 13/12/2015 15:47 (GMT+01:00) <br>To: postgis-users@lists.osgeo.org <br>Subject: [postgis-users] Any native compression strategies suited for a revisioning system? <br><br>I have been tasked with creating a revisioning system for geometries<br>stored by PostGIS. To avoid data duplication I thought about storing<br>only diffs but because that introduces other complications I am<br>thinking about just storing each revision in its entirety and having a<br>compression mechanism minimize size on disk.<br><br>However, it seems to me that, quite rightly, Postgres's compression<br>algorithm (PGLZ?) is not optimised for delta encoding or high<br>compression ratios. So are there any options short of me implementing<br>user-defined functions to wrap a compression library?<br><br>For clarity, with this method I am thinking each geometry would have a<br>corresponding row in which a field would hold all revisions in a JSON<br>data structure.<br><br><br>Peter<br>_______________________________________________<br>postgis-users mailing list<br>postgis-users@lists.osgeo.org<br>http://lists.osgeo.org/mailman/listinfo/postgis-users<br><br></body></html>