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