[postgis-devel] Bit setting to compress PostGIS geometries

[Paul Ramsey]

Is there a reason you avoid the ST_ prefix? All the "things we expect
users to call" have that. The postgis_ prefix has been used mostly for
administrative utility things.
I also kind of lean towards ST_ReducePrecision() which describe what
it does, rather than compress, which describes one of the use cases
(though I could, as usual, easily be swayed the other way).
ATB
p

On Tue, Mar 6, 2018 at 7:55 AM, Daniel Baston <dbaston at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel