|
Craig wrote: <snip> I can think of three workarounds. Hamish wrote: 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.<snip> 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. https://help.ubuntu.com/community/LinuxFilesystemsExplained? 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. </snip> 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? Craig |
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
