[postgis-devel] Bit setting to compress PostGIS geometries

[Björn Harrtell]

I really want to hack this in pure SQL to be able to run this on existing
databases. Seems possible without thinking to hard on the problem yet. :)

/Björn

Den 19 feb. 2018 22:07 skrev "Sandro Santilli" <strk at kbt.io>:

> On Mon, Feb 19, 2018 at 09:20:16AM -0500, Daniel Baston wrote:
>
> > We have one extra bit in the SRID, no? (There are 21 bits set aside for
> > SRID, but 2^20 > SRID_MAXIMUM). So we could combine this extra bit with
> the
> > 3 spare bits after the SRID and represent all meaningful values of
> > precision (1-15).
>
> Let's not consume all bits w/out leaving the door open for future
> expansion please.
>
> > Or we could store precision only in the 3 bits after the SRID, and not
> > allow all values of precision (there's little value in 1, 2, 3, 4, 12,
> 13,
> > and 14 in my opinion). We could also steal a bit from the flags
> ("readonly"
> > does not appear to be used).
>
> "readonly" is used internally by liblwgeom for memory management.
>
> > This all assumes that we want an implementation of precision based around
> > significant digits. That's convenient for this use case, but I'd guess
> many
> > users expect precision in the sense of grid spacing, as is used (I think)
> > with the topology functions.
>
> Yes, and GEOS fixed precision model. And SnapToGrid.
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180306/efa49f16/attachment.html>