<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Martin, that confirmation is really helpful. Should be a
simple fix now to amend the help text and avoid the confusion.<br>
</p>
<div class="moz-cite-prefix">Op 11-6-2024 om 22:14 schreef Martin
Davis:<br>
</div>
<blockquote type="cite"
cite="mid:CAK2ens1rC97U45Zjjs5b5q8DObz9kH4xMDwgWCXFJWSZsTmv9w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Yes, your interpretation is correct.
ST_ReducePrecision is only guaranteed to work on VALID
geometries. It will also work on *some* invalid geometries
(such as ones which are invalid due to containing adjacent - but
not overlapping - polygons). So the safest thing is to use
ST_MakeValid if there is doubt about whether the inputs are
valid.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2024 at
1:00 PM Marco Boeringa <<a
href="mailto:marco@boeringa.demon.nl" moz-do-not-send="true"
class="moz-txt-link-freetext">marco@boeringa.demon.nl</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">
<div>
<p>Hi,</p>
<p>Currently, the help page of PostGIS's ST_ReducePrecision
command more or less suggests that ST_ReducePrecision can
be used as kind of "drop-in" replacement of ST_MakeValid.
The actual text reads:</p>
<p><i>"Returns a valid geometry with all points rounded to
the provided grid tolerance, and features below the
tolerance removed.<br>
<br>
Unlike ST_SnapToGrid the returned geometry will be
valid, with no ring self-intersections or collapsed
components.</i></p>
<p> <i>Precision reduction can be used to: </i></p>
<div>
<ul style="list-style-type:disc">
<li>
<p><i> match coordinate precision to the data accuracy
</i></p>
</li>
<li>
<p><i> reduce the number of coordinates needed to
represent a geometry </i></p>
</li>
<li>
<p><i> ensure valid geometry output to formats which
use lower precision (e.g. text formats such as
WKT, GeoJSON or KML when the number of output
decimal places is limited). </i></p>
</li>
<li>
<p><i> export valid geometry to systems which use
lower or limited precision (e.g. SDE, Oracle
tolerance value)"</i></p>
</li>
</ul>
</div>
<p>However, a first test replacing:</p>
<p>ST_CollectionExtract(ST_MakeValid(<SOME OTHER
GENERALIZATION CODE>),3)</p>
<p>with:</p>
<p>ST_ReducePrecision(<SOME OTHER GENERALIZATION
CODE>),<GRID SIZE>)</p>
<p>failed on some geometries with a processing error. <br>
</p>
<p>Replacing the first try with:<br>
</p>
<p>ST_ReducePrecision(ST_CollectionExtract(ST_MakeValid(<SOME
OTHER GENERALIZATION CODE>),3),<GRID SIZE>)</p>
<p>did succeed.</p>
<p>This suggest to me that the help page should actually
read something like:</p>
<p><i>"Returns a geometry with all points rounded to the
provided grid tolerance, and features below the
tolerance removed.<br>
<br>
Unlike ST_SnapToGrid the returned geometry is guaranteed
to be valid, with no ring self-intersections or
collapsed components, if the input geometry itself is
valid. If the input geometry is invalid, there is no
guarantee the output will be valid. Use ST_MakeValid to
ensure the input is valid before running this command if
the input data may contain invalid geometries."</i></p>
<p>Is my interpretation of how<i> </i>ST_ReducePrecision
handles validity as reflected by this suggested updated
help text correct?<i><br>
</i></p>
<p>Marco<i><br>
</i></p>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>