[postgis-devel] Bit setting to compress PostGIS geometries

[Daniel Baston]

It does raise the question of whether it would be useful to have a
SQL-level function that takes a callback and applies it to each coordinate
of a geometry...

As far as merging this in, are there objections to the function name
"postgis_compress_geometry" ? While the compression is actually happening
at the Postgres level, I think this name captures the net result of calling
the function, doesn't require the user to understand the internal mechanism
of compression, and suggests that use of the function alters the input data
and may affect performance.

Dan

On Tue, Mar 6, 2018 at 3:01 AM, Björn Harrtell <bjorn.harrtell at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> 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/db0cbcc8/attachment-0001.html>