[GRASS-dev] [GRASS GIS] #3369: Followup to area calculation fix in changeset 71169

[GRASS GIS]

#3369: Followup to area calculation fix in changeset 71169
--------------------------+-------------------------
  Reporter:  ndawson      |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:
 Component:  Default      |    Version:  unspecified
Resolution:               |   Keywords:
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mmetz):

 Replying to [ticket:3369 ndawson]:
 > While investigating the QGIS ticket https://issues.qgis.org/issues/16820
 I came across changeset 71169 as a fix for a similar issue in grass.
 >
 > When porting this fix across to QGIS, I had to modify the thres constant
 value to 0.7e-7, outside of the 1e-4 to 1e-7 range noted in the comment in
 area_poly1.c. I found this to be the maximum possible value which allowed
 an existing QGIS regression test to pass:
 >
 >
 https://github.com/qgis/QGIS/blob/master/tests/src/core/testqgsdistancearea.cpp#L371
 (as a result of https://issues.qgis.org/issues/14675)

 About the first example (regression14675): what is SRSid 145L in EPSG or
 proj4 terms?

 About the second example (regression16820): GRASS reports an area of
 43.3280133198665 sqm in the original CRS, and an area of 43.2035658006178
 sqm reprojected to latlon. The QGIS test has a reference of 43.183369 sqm,
 i.e. the projected GRASS result is a bit closer to the original than the
 QGIS reference. The threshold as used in GRASS seems to work fine here.

 >
 > So this ticket is just a heads-up that the grass threshold value of 1e-6
 may not be suitable, and this may need lowering to fix a real-world area
 calculation issue.

 Waiting for SRS info on regression14675 to test in GRASS.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3369#comment:1>
GRASS GIS <https://grass.osgeo.org>