[postgis-tickets] [PostGIS] #5425: ST_SnapToGrid returns not correct data

[PostGIS]

#5425: ST_SnapToGrid returns not correct data
----------------------+---------------------------------------
  Reporter:  tmazuga  |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS Fund Me
 Component:  postgis  |    Version:  master
Resolution:           |   Keywords:  ST_SnapToGrid, robustness
----------------------+---------------------------------------
Changes (by strk):

 * keywords:  ST_SnapToGrid => ST_SnapToGrid, robustness
 * version:  3.3.x => master
 * milestone:  PostGIS 3.3.4 => PostGIS Fund Me

Comment:

 It looks like it's the text representation having gotten more detail. If
 you grid to 0.001 you probably only want 3 decimal digits at most, anyway.
 In this case even the asking for 9 give the answer you expect (it takes 10
 decimal digits to show the unexpected digits, showing up at the 16th
 figure)

 Simplified testcase:

 test5425.sql
 {{{
 SELECT ST_AsText(ST_SnapToGrid('LINESTRING(674169.89 198051.38,674197.7
 198065.55,674200.36 198052.38)', 0.001));
 }}}

 test5425_expected
 {{{
 LINESTRING(674169.89 198051.38,674197.7 198065.55,674200.36 198052.38)
 }}}

 The test succeeds with 3.0.8
 The test succeeds with 3.0.8-13-g72385411f (current tip of stable-3.0
 branch)
 The test fails    with 3.1.0
 The test fails    with 3.1.9-7-g0d745994f (current tip of stable-3.1
 branch)

 Note that using ST_Equals shows that the actual point isn't as round as
 reported by ST_AsText even in 3.0. The following query will return true in
 both 3.0 and 3.1, while changing those rightmost digits ends up reporting
 false.

 {{{
 SELECT ST_Equals(
   ST_PointN(
     ST_SnapToGrid(g, 0.001),
     2
   ),
   --'POINT(674197.7 198065.55)' -- this gives false
   'POINT(674197.7000000001 198065.55000000002)' -- this gives true
   --'POINT(674197.7000000001 198065.55000000001)' -- this also gives true
 )
 FROM inp;
 }}}

 The issue of points not being on the expected grid has always existed and
 is a numerical robustness.

 ST_AsText giving more detail seems to be an enhancement, not a
 degradation.

 For this reason I'm retargetting this ticket to the {{{ Fund Me }}}
 milestone.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5425#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.