[postgis-devel] Bit setting to compress PostGIS geometries

[Paul Ramsey]

I'm fine w/ "quantize" and a detailed entry in the docs about the
magic you're doing (btw, will your magic work on big-endian
architectures too? and whatever ARM is)

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