[GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

[GRASS GIS]

#3356: v.to.db: incorrect area calculations in lat-long location
-----------------------------------+-------------------------
 Reporter:  mlennert               |      Owner:  grass-dev@…
     Type:  defect                 |     Status:  new
 Priority:  normal                 |  Milestone:  7.4.0
Component:  Vector                 |    Version:  svn-trunk
 Keywords:  v.to.db area lat-long  |        CPU:  Unspecified
 Platform:  Unspecified            |
-----------------------------------+-------------------------
 [https://lists.osgeo.org/pipermail/grass-user/2017-May/076533.html As
 reported by James Duffy on the ML], using the attached shapefile, raises
 the following issues:

 When I import the polygon in an EPSG 4326 location, I get the same result
 as reported by James:


 {{{
 v.report training op=area u=me
 cat|id|area
 1|1|38.2256243922775
 }}}

 But when I reproject it to a UTM 43N (EPSG 32743) location, I get a
 different area, which is close to what QGIS gives as area:

 {{{
 v.proj location=LL_WGS84 mapset=mlennert input=training
 output=training_reproj_grass
 v.report training_reproj_grass op=area u=me
 cat|id|area
 1|1|0.126369981910102
 }}}


 Interestingly, when I create a buffer around the area in the lat-long
 location:

 {{{
 v.buffer training dist=0.0001 out=training_buff_0_0001
 }}}

 The area measurement in GRASS is again very close to the one in QGIS:


 {{{
 v.report training_buff_0_0001 op=area u=me
 cat|area
 1|419.188654810375
 }}}


 {{{
 $area in field calculator in QGIS:
 425.1112801
 }}}

 In addition, in the ESPG 4326 location, it is impossible to zoom to the
 original polygon as it seems to go below the zoom capacity of the GUI:

 {{{
 "Failed to run command 'd.vect map=training at mlennert
 type=point,line,boundary,area,face width=1'. Details:


 GRASS_INFO_ERROR(22724,1): Invalid n-s resolution field: 0.000000 "
 }}}


 Although these two might be unrelated, I do feel that there might be an
 issue with floating point precision somewhere.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3356>
GRASS GIS <https://grass.osgeo.org>