[GRASS-dev] [GRASS GIS] #2658: [PATCH] v.to.db compactness gives wrong results in feet location (was: v.to.db compactness gives wrong results in feet location)

[GRASS GIS]

#2658: [PATCH] v.to.db compactness gives wrong results in feet location
--------------------------+-----------------------------------------------
  Reporter:  annakrat     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  major        |  Milestone:  7.0.1
 Component:  LibGIS       |    Version:  svn-releasebranch70
Resolution:               |   Keywords:  v.to.db, units, area, compactness
       CPU:  Unspecified  |   Platform:  All
--------------------------+-----------------------------------------------

Comment (by mlennert):

 Replying to [ticket:2658 annakrat]:
 > I was looking in the source code of v.to.db to understand if computed
 area is in meters squared or location units (feet in my case). I realized
 area is converted to meters squared, however, perimeter seems to be in map
 units (feet). Therefore compactness is wrong when units are not meters
 (latlon is fine I guess). Setting feet as units doesn't influence
 compactness computation.
 >
 > Currently the library functions for computing area and perimeter don't
 behave consistently.

 And perimeter information is wrong when using unit=feet parameter:


 {{{
 g.region s=0 n=10 w=0 e=10 res=1
 v.mkgrid map=mygrid box=1,1
 }}}

 Then, when asking for perimeter without unit parameter, you get the
 correct perimeter in feet:


 {{{
 > v.to.db -p mygrid op=perimeter
 Reading areas...
  100%
 cat|perimeter
 1|4
 2|4
 3|4
 [...]
 }}}

 However, when you explicitly ask for feet, the result is wrong since
 v.to.db assumes that the perimeter is in meters and converts to feet:

 {{{
 > v.to.db -p mygrid op=perimeter unit=feet
 Reading areas...
  100%
 cat|perimeter
 1|13.1233595800525
 2|13.1233595800525
 3|13.1233595800525
 [...]
 }}}

 Currently, v.to.db seems to assume that all length and area values are in
 meters by default and converts them to the requested unit. For now I
 suggest to respect that assumption, unless the user explicitly asks for
 another unit. I'll attach a patch which attempts to do this. Please test.

 The only inconvenience is that when the user asks for the original units
 (e.g. feet) the values are approximate only. Example for a 5 feet line:


 {{{
 > v.to.db -p line op=length unit=feet
 Reading features...
  100%
 cat|length
 1|5.00001000001999
 }}}

 The other (probably cleaner) option would be to create a new function for
 area calculation that returns area in location units and modify v.to.db to
 always return location units. However this demands a bit more modification
 of v.to.db.

 In any case, whatever we chose, this will probably break scripts that rely
 on the existing behavior of v.to.db (even though I consider that behavior
 as a clear bug).

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