<div dir="ltr"><div><div><div><div><div><div class="gmail_quote">On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <span dir="ltr"><<a target="_blank" href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">There is at least SnapToGrid:<br>
# select ST_SnapToGrid((ST_DumpPoints(<wbr>mypoly.geom)).geom, 0.1) from mypoly;<br>
<br>
:Stefan<br clear="all"></blockquote></div><br>Hm, i considered that before, but now i can't say why i discarded the thought.<br></div>One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.<br></div>But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.<br></div>It is easy to understand what is happening too, so that is an advantage.<br></div><div>BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.<br></div><br>Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?<br><br></div>Cheers,<br><br><br><div class="gmail_extra">-- <br><div class="gmail_signature"><div dir="ltr">Willy-Bas Loos<br></div></div>
</div></div>