[postgis-devel] Bit setting to compress PostGIS geometries

[Daniel Baston]

I guess what I'm struggling with is whether this function will play nice
with an
eventual precision implementation along the lines of what Darafei described.
Since I'm unsure of that, I have an inclination to bury it a bit as an
internal
function.

My hesitation with the "reduce precision" terminology is that, in the
absence of
a complete precision implementation, users often turn to ST_SnapToGrid to
perform precision reduction, and its results are inconsistent with this
function.

Take as an example this input geometry:

LINESTRING(-96.915638 37.214606,-96.915629 37.215194,-96.915626
37.21539,-96.914793 37.215383)

Say we want to reduce this to 2 digits of precision. SELECT
ST_AsText(ST_SnapToGrid(g, 1e-2)) outputs the following, which I think is in
line with user expectations for "reducing precision":

LINESTRING(-96.92 37.21,-96.92 37.22,-96.91 37.22)

Wheres ST_AsText(ST_UnnamedFunction(g, 2)) outputs this:

LINESTRING(-96.9140625 37.212890625,-96.9140625 37.21484375,-96.9140625
37.21484375,-96.9140625 37.21484375)

If we had a complete precision implementation, ST_AsText would know that it
should only output two digits of precision in this case. But since we don't,
calling the bit-setting "precision reduction" seems like it could be
confusing.

Darafei's suggestion to use "quantize" in the name is appealing to me in
that
it's in line with other references to the same technique (e.g.,
https://www.geosci-model-dev.net/9/3199/2016/ which describes techniques
similar
to this one)

Dan

On Thu, Mar 8, 2018 at 8:32 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> 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
> _______________________________________________
> 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/6a34555d/attachment.html>