#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@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>