[postgis-devel] Precision Reduction?

[Darafei "Komяpa" Praliaskouski]

Regarding naming: we already have duality of ST_Simplify <->
ST_SimplifyPreserveTopology, so if we want to follow it as an agreement, it
has to be ST_SnapToGridPreserveTopology. If that looks wrong then we may
want to consider the exposure of this function together with naming
ST_SimplifyPreserveTopology.

Another recent precision reducer we have is ST_QuantizeCoordinates. Can
GEOS be bent to provide the same behavior on a non-even grid with last bits
set to 0 with guarantees on validity of output?

On Wed, Nov 11, 2020 at 7:27 PM Martin Davis <mtnclimb at gmail.com> wrote:

> I am neutral about encoding precision in the data or in the schema.  As
> Darafei points out it raises a raft of tricky questions about what should
> be made precise, the semantics of spatial predicates, and what to do about
> mixed precision. It's a far bigger change than what Paul is asking about,
> since it requires many operations to be enhanced to support precise output.
>
> Providing ST_PrecisionReduce may or may not be a small step in that
> direction.  But it lets users and the development team get some experience
> with how and when to enforce precision.
>
> On Wed, Nov 11, 2020 at 2:06 AM Sandro Santilli <strk at kbt.io> wrote:
>
>> I think we should add a precision field to the Geometry type
>> so that once precision is set on a geometry it sticks and can
>> be passed around, in particular to GEOS functions for retaining
>> the precision in output (basically using fixed precision all
>> the way).
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



-- 
Darafei "Komяpa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20201111/de3035d5/attachment.html>