[postgis-devel] Bit setting to compress PostGIS geometries

[Darafei "Komяpa" Praliaskouski]

Hi,

>From the perfectionist point of view, proposed solution in this form is a
hack that зшуксуы several abstraction levels, produces invalid geometries,
and calls itself by the name of side effect it does to completely unrelated
mechanism of a software another team of people is responsible of. :)

Somewhat better way to handle it would be to have some sort of dataset
profile attached to table (or to row, in manner similar to SRID, or
replacing SRID and storing it as dataset parameter) that will tell where
significance ends for these objects, precision model, SRID and projection
as such, whether we want to enforce validity for all entries, what would be
the rules of handling slivers, how do we detect slivers based on
definitions of precision, and what do we do if clearance of polygon in
smaller than precision. Then you can handle it transparently and don't need
such function on SQL level at all.

But, perfect is the enemy of good. Designing a method to store such
description and pass it to all functions, including in/out and zero rows
aggregates is not going to be simple.

Meanwhile power users can get quick gains from it, knowing that what they
do is a hack. They already do this in much cryptic ways, see discussion on
Voronoi and SnapToGrid with powers of two. They may want to reuse your
function for the task.

This leads to even more confusion: why on Earth is
postgis_compress_geometry is going to fix points input for
ST_VoronoiPolygons? :)

We've had this kind of confusion with ST_Buffer(geom,0), that used to be
"the way" of fixing invalids before introduction of ST_MakeValid, but works
just by accidental lack of obvious short-circuit, and ST_Buffer, unlike
overlay functions, happening to chose to ignore the fact that passed input
is invalid.

So, my thoughts:
 - it's a hack, so it's better sound long and scary for people who don't
understand it;
 - it's a clever useful hack, so it's better be in PostGIS for those who
can utilize its side effects, be that compression or algorithm robustness
or something we don't yet know about;
 - if you're seeking for other words to call the function, quantization may
be the word: https://en.wikipedia.org/wiki/Quantization_(signal_processing)



чт, 8 мар. 2018 г. в 4:22, Daniel Baston <dbaston at gmail.com>:

> Agreed, nothing will be compressed if the user selects an incompressible
> storage type. We could use a function name that describes exactly what it
> does ("postgis_zero_out_bits_not_required_to_maintain_specified_precision")
> but I don't think that really creates less confusion (for one, it doesn't
> convey why you would want to do this). I'm very open to other ideas, though.
>
> Dan
>
> On Wed, Mar 7, 2018 at 10:31 AM, Darafei "Komяpa" Praliaskouski <
> me at komzpa.net> wrote:
>
>>
>> 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.
>>>
>>
>> compress_geometry will not kick in if column type is altered to EXTERNAL
>> or PLAIN:
>> https://www.postgresql.org/docs/10/static/storage-toast.html
>>
>> I would expect compress_geometry to change internal representation to
>> some zigzag delta encoded thing, but not to zero out last bits.
>>
>> _______________________________________________
>> 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/20180308/68a9fe1b/attachment.html>