<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. :)<div dir="auto"><div dir="auto"><br></div><div dir="auto">/Björn</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">Den 19 feb. 2018 22:07 skrev "Sandro Santilli" <<a href="mailto:strk@kbt.io">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">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></blockquote></div></div>