#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
----------------------+-----------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: | Platform: Linux
Cpu: x86-32 |
----------------------+-----------------------------------------------------
When I'm doing v.rast.stats with grass (v6.4.2) and a polygon with a dbf
db, the results come back for each row with two decimental numbers. The
column attribute is of type "DOUBLE PRECISION" . That presicion is not
enough.
for grass7 the v.rast.stats come back with much better presicion(<6
decimental digits)
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by elcol):
I can confirm this bug. I also only get 2 decimals instead of double
precision for column attributes, also when using v.db.select. I am using
GRASS 6.4.2
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by hamish):
Replying to [comment:4 elcol]:
> I can confirm this bug. I also only get 2 decimals instead of double
precision
> for column attributes, also when using v.db.select. I am using GRASS
6.4.2
is the database backend dbf?
if so, can you look at it with a utility like 'dbview' or
{Open|Libre}Office Calc and inspect the data values in it? Perhaps the raw
data is that way and v.db.* is just rounding off the .000000000s
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by elcol):
Replying to [comment:5 hamish]:
> Replying to [comment:4 elcol]:
> > I can confirm this bug. I also only get 2 decimals instead of double
precision
> > for column attributes, also when using v.db.select. I am using GRASS
6.4.2
>
> is the database backend dbf?
>
> if so, can you look at it with a utility like 'dbview' or
{Open|Libre}Office Calc and inspect the data values in it? Perhaps the raw
data is that way and v.db.* is just rounding off the .000000000s
>
>
> Hamish
I'm using the default dbf backend. I've just checked the .dbf file with
LibreOffice, and all data has only 2 decimals in the actual file too.
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by hamish):
Replying to [comment:6 elcol]:
> I'm using the default dbf backend. I've just checked the .dbf file with
> LibreOffice, and all data has only 2 decimals in the actual file too.
ok, how was the data imported? was the original source like that too?
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by ElcoL):
Replying to [comment:7 hamish]:
> Replying to [comment:6 elcol]:
> > I'm using the default dbf backend. I've just checked the .dbf file
with
> > LibreOffice, and all data has only 2 decimals in the actual file too.
>
> ok, how was the data imported? was the original source like that too?
>
>
> Hamish
Its slope data that i got using r.slope.aspect on a DEM. Map query reports
up to 10 decimals, so the dataset looks normal.
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by hamish):
Replying to [comment:8 ElcoL]:
> Its slope data that i got using r.slope.aspect on a DEM. Map query
reports
> up to 10 decimals, so the dataset looks normal.
Which method did you use to convert the raster result to a vector map?
i.e. exact command line arguments used with v.rast.stats? Did you use the
-e flag? what was the vector polygon map like? does 'r.univar -t' look
normal on the query map?
Is the normal looking map query of the DEM or the result of
r.slope.aspect?
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by ElcoL):
Replying to [comment:10 hamish]:
> .. and can you try with GRASS 6.4.3rc4 or a 6.4.3svn nightly snapshot?
which Linux distro are you using?
>
>
> Hamish
I was running GRASS 6.4.2 on Ubuntu 13.04, but I have just reproduced the
error too after compiling the current svn snapshot (ie. GRASS 6.4.3svn).
Here's the exact command for v.rast.stats:
v.rast.stats -c vector=na_pfaf_alpha@PERMANENT
raster=watertable_gradient_fraction@PERMANENT colprefix=wtg
the watertable_gradient_fraction@PERMANENT raster is the result of
r.slope.aspect and looks normal (ie more than 2 decimals). The resulting
attribute table of na_pfaf_alpha@PERMANENT only contains 2 decimals in
queries or when inspecting the .dbf file with gnumeric or libreoffice
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by ElcoL):
Replying to [comment:12 hamish]:
> can you also provide the r.slope.aspect command? (r.info -h).
>
> and can you reproduce it with one of the sample datasets? (spearfish or
NC, so I can try to reproduce it here too)
>
>
> thanks,
> Hamish
>
> ps- no need to explicitly state @PERMANENT, it's automatically in the
map search path.
seems this came in with r48058 as part of a bulk merge with another
(faster) version of the script, so in 6.4.2+ but not the old+slow 6.4.1
version. I don't see a reason to keep it as %.2f instead of
%.{something}g, any hints Otto?
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
--------------------------+-------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Vector | Version: 6.4.2
Keywords: v.rast.stats | Platform: Linux
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Changes (by neteler):
* milestone: 6.4.3 => 6.4.4
Comment:
Replying to [comment:14 hamish]:
...
> It happens because the awk command specifically sets the print format to
"%.2f".
...
> seems this came in with r48058 as part of a bulk merge ...
>
>I don't see a reason to keep it as %.2f instead of %.{something}g, any
hints Otto?
#1747: v.rast.stats on dbf shapefile not enough precision even with DOUBLE
PRECISION
-----------------------+----------------------------------------------------
Reporter: vesnikos | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.4
Component: Vector | Version: 6.4.2
Resolution: fixed | Keywords: v.rast.stats
Platform: Linux | Cpu: x86-32
-----------------------+----------------------------------------------------
Changes (by neteler):
* status: new => closed
* resolution: => fixed
Comment:
In r57560 it got already changed to %.15g, so that looks like solved.
Test case (long line broken by me for trac formatting):
{{{
v.db.connect mysoils_wake -p
g.copy vect=soils_wake,mysoils_wake
v.rast.stats vector=mysoils_wake raster=slope colprefix=slope
v.db.select mysoils_wake
...
3364|120028|1653.86|35468|34409|Co|B|34|0.142551511526108|2.868412733078|
2.7258612215519|1.10701639950275|0.692389694214987|0.479403488655124|
62.5455679361202|37.6385575830936
...
d.mon x0
d.rast slope
d.vect type=boundary
}}}
To speed v.rast.stats up I added DB TRANSACTION in r60243, r60244.
