v.to.db: incorrect area calculations in lat-long location
|Reported by:||mlennert||Owned by:|
|Keywords:||v.to.db area lat-long||Cc:|
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.