[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 [comment:2 ndawson]:
 > > About the first example (regression14675): what is SRSid 145L in EPSG
 or proj4 terms?
 >
 > Argh, missed that sorry. It's EPSG:2154.

 Thanks! Here are the results

  * QGIS reference: 0.83301
  * GRASS in EPSG:2154: 0.86121968362156
  * GRASS in latlon: 3.3238796585328

 I had to lower the threshold to 1e-8 in order to get

  * GRASS in latlon: 0.86134805688084
 >
 >
 > > 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.
 >
 > Hmm - good point. To eliminate any discrepancies due to projection
 handling/some other factor I tried using the original threshold of 1e-6 in
 QGIS and got an area of
 > 43.3280029296875.
 >
 > I can't find a reliable threshold which satisfies both these
 requirements. Ubuntu 16.04 with a threshold of 0.8e-7 does, but the same
 threshold on Fedora 25 fails both tests.

 This threshold method is not perfect. I found that the threshold must be
 larger, the closer it gets to the equator, and smaller, the closer it gets
 to the poles.

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