<div dir="ltr"><div><div>I guess what I'm struggling with is whether this function will play nice with an</div><div>eventual precision implementation along the lines of what Darafei described.</div><div>Since I'm unsure of that, I have an inclination to bury it a bit as an internal</div><div>function. </div><div><br></div><div>My hesitation with the "reduce precision" terminology is that, in the absence of</div><div>a complete precision implementation, users often turn to ST_SnapToGrid to</div><div>perform precision reduction, and its results are inconsistent with this function.</div><div><br></div><div>Take as an example this input geometry:</div><div><br></div><div>LINESTRING(-96.915638 37.214606,-96.915629 37.215194,-96.915626</div><div>37.21539,-96.914793 37.215383)</div><div><br></div><div>Say we want to reduce this to 2 digits of precision. SELECT</div><div>ST_AsText(ST_SnapToGrid(g, 1e-2)) outputs the following, which I think is in</div><div>line with user expectations for "reducing precision":</div><div><br></div><div>LINESTRING(-96.92 37.21,-96.92 37.22,-96.91 37.22)</div><div><br></div><div>Wheres ST_AsText(ST_UnnamedFunction(g, 2)) outputs this:</div><div><br></div><div>LINESTRING(-96.9140625 37.212890625,-96.9140625 37.21484375,-96.9140625</div><div>37.21484375,-96.9140625 37.21484375)</div><div><br></div><div>If we had a complete precision implementation, ST_AsText would know that it</div><div>should only output two digits of precision in this case. But since we don't,</div><div>calling the bit-setting "precision reduction" seems like it could be confusing.</div><div><br></div><div>Darafei's suggestion to use "quantize" in the name is appealing to me in that</div><div>it's in line with other references to the same technique (e.g.,</div><div><a href="https://www.geosci-model-dev.net/9/3199/2016/">https://www.geosci-model-dev.net/9/3199/2016/</a> which describes techniques similar</div><div>to this one)</div><div><br></div></div><div>Dan</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 8, 2018 at 8:32 AM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there a reason you avoid the ST_ prefix? All the "things we expect<br>
users to call" have that. The postgis_ prefix has been used mostly for<br>
administrative utility things.<br>
I also kind of lean towards ST_ReducePrecision() which describe what<br>
it does, rather than compress, which describes one of the use cases<br>
(though I could, as usual, easily be swayed the other way).<br>
ATB<br>
<span class="gmail-HOEnZb"><font color="#888888">p<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Tue, Mar 6, 2018 at 7:55 AM, Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>> wrote:<br>
> It does raise the question of whether it would be useful to have a SQL-level<br>
> function that takes a callback and applies it to each coordinate of a<br>
> geometry...<br>
><br>
> As far as merging this in, are there objections to the function name<br>
> "postgis_compress_geometry" ? While the compression is actually happening at<br>
> the Postgres level, I think this name captures the net result of calling the<br>
> function, doesn't require the user to understand the internal mechanism of<br>
> compression, and suggests that use of the function alters the input data and<br>
> may affect performance.<br>
><br>
> Dan<br>
><br>
> On Tue, Mar 6, 2018 at 3:01 AM, Björn Harrtell <<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I really want to hack this in pure SQL to be able to run this on existing<br>
>> databases. Seems possible without thinking to hard on the problem yet. :)<br>
>><br>
>> /Björn<br>
>><br>
>> Den 19 feb. 2018 22:07 skrev "Sandro Santilli" <<a href="mailto:strk@kbt.io">strk@kbt.io</a>>:<br>
>>><br>
>>> 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<br>
>>> > 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,<br>
>>> > 13,<br>
>>> > and 14 in my opinion). We could also steal a bit from the flags<br>
>>> > ("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<br>
>>> > around<br>
>>> > significant digits. That's convenient for this use case, but I'd guess<br>
>>> > many<br>
>>> > users expect precision in the sense of grid spacing, as is used (I<br>
>>> > 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><br>
>><br>
>><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>
><br>
><br>
><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>
______________________________<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></div></div></blockquote></div><br></div></div>