[GRASS-dev] [GRASS GIS] #2281: t.rast.aggregate unnecessaryly slow with limited number of maps
GRASS GIS
trac at osgeo.org
Mon May 5 00:46:47 PDT 2014
#2281: t.rast.aggregate unnecessaryly slow with limited number of maps
-------------------------+--------------------------------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
I was having some trouble with t.rast.aggregate which was much slower than
running the same operation directly in r.series, making t.rast.aggregate
almost useless (see performance comparison below).
I tracked the problem down to the usage of the z-flag in r.series.
Please find attached a patch for aggregation.py, which adds a check for
the number of maps to be opened in r.series and uses the z- only if there
is a danger for hitting a limit for open files (fix number of 1000 in the
patch).
g.region -up
projection: 1 (UTM)
zone: 33
datum: etrs89
ellipsoid: grs80
north: 8000000
south: 6450000
west: -75000
east: 1120000
nsres: 1000
ewres: 1000
rows: 1550
cols: 1195
cells: 1852250
time t.rast.aggregate input=temperature method=average output=test
base=test granularity="1 months" sampling=during where="start_time >=
'2012-12-01' AND start_time < '2013-01-01'" --o --v
Percent complete...
100%
Update metadata, spatial and temporal extent from all registered maps of
real 25m23.127s
user 9m56.357s
sys 15m22.446s
time r.series input=$(g.mlist type=rast pattern=tm_2012_12* separator=",")
output=test method=average --o
100%
real 0m4.588s
user 0m3.492s
sys 0m0.764s
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2281>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list