[postgis-devel] Precision Reduction?

[Darafei "Komяpa" Praliaskouski]

I expect to be able to get the result of this function via
ST_UnaryUnion(geom, precision), or, if that's not available, as
ST_Union(geom, 'GEOMETRYCOLLECTION EMPTY', precision) for the most cases
with GEOS 3.9.

So +1 on 3.2 if above is true.

On Wed, Nov 11, 2020 at 10:12 PM Regina Obe <lr at pcorp.us> wrote:

> -1 – please no more questionable functions  we might need to take out in
> 3.1.0 release.
>
>
>
> Let’s be content with what we have already with the new gridSize args strk
> introduced and focus on bullet testing the geos 3.9.
>
>
>
> The reality is a good chunk of people aren’t going to be using GEOS 3.9 in
> PostGIS 3.1 so you are creating a bunch of features that few can use and
> that yikes you might kick yourself in the ass when you realize you don’t
> like the new names you came up with.
>
> Let’s just put all this dreamy talk into the 3.2 release milestone. PLEASE
>
>
>
> Thanks,
>
> Regina
>
>
>
> *From:* postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] *On
> Behalf Of *Darafei "Kom?pa" Praliaskouski
> *Sent:* Wednesday, November 11, 2020 11:53 AM
> *To:* PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] Precision Reduction?
>
>
>
> 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/
> _______________________________________________
> 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/f27f328a/attachment-0001.html>