<div dir="ltr"><div>Hi,</div><div><br></div><div>From the perfectionist point of view, proposed solution in this form is a hack that зшуксуы several abstraction levels, produces invalid geometries, and calls itself by the name of side effect it does to completely unrelated mechanism of a software another team of people is responsible of. :)<br><br>Somewhat better way to handle it would be to have some sort of dataset profile attached to table (or to row, in manner similar to SRID, or replacing SRID and storing it as dataset parameter) that will tell where significance ends for these objects, precision model, SRID and projection as such, whether we want to enforce validity for all entries, what would be the rules of handling slivers, how do we detect slivers based on definitions of precision, and what do we do if clearance of polygon in smaller than precision. Then you can handle it transparently and don't need such function on SQL level at all.<br></div><div><br></div><div>But, perfect is the enemy of good. Designing a method to store such description and pass it to all functions, including in/out and zero rows aggregates is not going to be simple.</div><div><br></div><div>Meanwhile power users can get quick gains from it, knowing that what they do is a hack. They already do this in much cryptic ways, see discussion on Voronoi and SnapToGrid with powers of two. They may want to reuse your function for the task.</div><div><br></div><div>This leads to even more confusion: why on Earth is postgis_compress_geometry is going to fix points input for ST_VoronoiPolygons? :)</div><div><br></div><div>We've had this kind of confusion with ST_Buffer(geom,0), that used to be "the way" of fixing invalids before introduction of ST_MakeValid, but works just by accidental lack of obvious short-circuit, and ST_Buffer, unlike overlay functions, happening to chose to ignore the fact that passed input is invalid.<br><br>So, my thoughts:</div><div> - it's a hack, so it's better sound long and scary for people who don't understand it;</div><div> - it's a clever useful hack, so it's better be in PostGIS for those who can utilize its side effects, be that compression or algorithm robustness or something we don't yet know about;<br> - if you're seeking for other words to call the function, quantization may be the word: <a href="https://en.wikipedia.org/wiki/Quantization_(signal_processing">https://en.wikipedia.org/wiki/Quantization_(signal_processing</a>)</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">чт, 8 мар. 2018 г. в 4:22, Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agreed, nothing will be compressed if the user selects an incompressible storage type. We could use a function name that describes exactly what it does ("postgis_zero_out_bits_not_required_to_maintain_specified_precision") but I don't think that really creates less confusion (for one, it doesn't convey why you would want to do this). I'm very open to other ideas, though.<div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 7, 2018 at 10:31 AM, Darafei "Komяpa" Praliaskouski <span dir="ltr"><<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div></span><div>compress_geometry will not kick in if column type is altered to EXTERNAL or PLAIN:<br><a href="https://www.postgresql.org/docs/10/static/storage-toast.html" target="_blank">https://www.postgresql.org/docs/10/static/storage-toast.html</a> <br><br></div><div>I would expect compress_geometry to change internal representation to some zigzag delta encoded thing, but not to zero out last bits.</div></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<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/mailman/listinfo/postgis-devel</a><br></blockquote></div></div>
_______________________________________________<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/mailman/listinfo/postgis-devel</a></blockquote></div>