<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Craig wrote:<br>
<cite></cite>&lt;snip&gt;<br>
</tt>
<blockquote type="cite"><tt>I can think of three workarounds.
  <br>
  <br>
1. &nbsp;Enter Rainer Krug and MapServer.
  <br>
I don't think my time frames allow for learning another software suite
right now.
  <br>
  <br>
2. &nbsp;Use a script to build a .grc file with a group for gis.m.
  <br>
Before attempting this I would like to know if there are any limits to
the number of layers that can be loaded.
  <br>
  <br>
3. &nbsp;Use r.patch to build one mosaic for each band.
&lt;/snip&gt;</tt></blockquote>
<tt><br>
Hamish wrote:</tt>
<blockquote cite="mid:410613.5969.qm@web45807.mail.sp1.yahoo.com"
 type="cite">
  <pre wrap=""><tt>&lt;snip&gt;
Your region is really really huge, I might suggest making 4 smaller
tiles out of it instead of one master map. I hope you compiled with LFS
(large file support) and your OS is 64bit.

</tt></pre>
</blockquote>
<tt>I wasn't aware that 32 vs 64 bit architecture affected the maximum
file size (RAM size - Yes). I read the following article and since I
compiled with LFS on an ext3 filesystem I thought I was good for 2TB.<br>
<a class="moz-txt-link-freetext" href="https://help.ubuntu.com/community/LinuxFilesystemsExplained">https://help.ubuntu.com/community/LinuxFilesystemsExplained</a>?<br>
<br>
</tt>
<blockquote cite="mid:410613.5969.qm@web45807.mail.sp1.yahoo.com"
 type="cite">
  <pre wrap=""><tt>By using 4 or more smaller region tiles to do the patch of non-
overlapping maps it may spend less time looking through empty space so
will be a lot faster. ?

You can use 'g.region -g' + 'r.info -g' to exclude maps which do not at
all fall in the output region. (this optimization might be built
directly into r.series?)

Alternate: let r.series run for x days. &lt;/snip&gt;
</tt></pre>
</blockquote>
<tt><br>
Thanks for the valuable suggestions. I'm still hoping to get some
comment on workaround number two mentioned above. Does anyone know of
any pitfalls with trying to load 139x3 layers into a group for gis.m?
I'm wondering if there might be a limit on the number of layers that
can be loaded or if loading so many layers might seriously affect the
performance of the map display?<br>
<br>
Craig<br>
</tt>
</body>
</html>