<div dir="ltr">It does raise the question of whether it would be useful to have a SQL-level function that takes a callback and applies it to each coordinate of a geometry...<div><br></div><div>As far as merging this in, are there objections to the function name "postgis_compress_geometry" ? While the compression is actually happening at the Postgres level, I think this name captures the net result of calling the function, doesn't require the user to understand the internal mechanism of compression, and suggests that use of the function alters the input data and may affect performance.</div><div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 6, 2018 at 3:01 AM, Björn Harrtell <span dir="ltr"><<a href="mailto:bjorn.harrtell@gmail.com" target="_blank">bjorn.harrtell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I really want to hack this in pure SQL to be able to run this on existing databases. Seems possible without thinking to hard on the problem yet. :)<span class="HOEnZb"><font color="#888888"><div dir="auto"><div dir="auto"><br></div><div dir="auto">/Björn</div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">Den 19 feb. 2018 22:07 skrev "Sandro Santilli" <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 19, 2018 at 09:20:16AM -0500, Daniel Baston wrote:<br>
<br>
> We have one extra bit in the SRID, no? (There are 21 bits set aside for<br>
> SRID, but 2^20 > SRID_MAXIMUM). So we could combine this extra bit with the<br>
> 3 spare bits after the SRID and represent all meaningful values of<br>
> precision (1-15).<br>
<br>
Let's not consume all bits w/out leaving the door open for future<br>
expansion please.<br>
<br>
> Or we could store precision only in the 3 bits after the SRID, and not<br>
> allow all values of precision (there's little value in 1, 2, 3, 4, 12, 13,<br>
> and 14 in my opinion). We could also steal a bit from the flags ("readonly"<br>
> does not appear to be used).<br>
<br>
"readonly" is used internally by liblwgeom for memory management.<br>
<br>
> This all assumes that we want an implementation of precision based around<br>
> significant digits. That's convenient for this use case, but I'd guess many<br>
> users expect precision in the sense of grid spacing, as is used (I think)<br>
> with the topology functions.<br>
<br>
Yes, and GEOS fixed precision model. And SnapToGrid.<br>
<br>
--strk;<br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/postgis-devel</a></blockquote></div></div>
</div></div><br>______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>