<div dir="ltr"><div>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.</div><div><br></div><div>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. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 11, 2020 at 2:06 AM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think we should add a precision field to the Geometry type<br>
so that once precision is set on a geometry it sticks and can<br>
be passed around, in particular to GEOS functions for retaining<br>
the precision in output (basically using fixed precision all<br>
the way).<br></blockquote></div></div>