I have 139 high resolution images, which I need to use as a background map
for some digitizing work. Loading 139x3 layers into gis.m is a real pain and
I can think of three workarounds.
1. Enter Rainer Krug and MapServer.
I don't think my time frames allow for learning another software suite right
now.
2. Use a script to build a .grc file with a group for gis.m.
Before attempting this I would like to know if there are any limits to the
number of layers that can be loaded.
3. Use r.patch to build one mosaic for each band.
I currently have r.patch running. It's been going for about 10.5hrs and has
reached 15%. Does this sound reasonable? I am starting to wonder if I'm
expecting too much. Here are my region settings:
Another question on the usage of r.patch:
I have passed the option --verbose to r.patch and I am expecting the program
to generate VERBOSE output, but all I'm seeing is the following:
Another question on the usage of r.patch:
I have passed the option --verbose to r.patch and I am expecting the program
to generate VERBOSE output, but all I'm seeing is the following:
I don't know what to expect, but was hoping for something like:
r.patch progress:
Currently processing map: abc.red, progress: 80%
Total progress: 15%
This may be something to be added to the wishlist?
--verbose is a no-op for most modules. The module needs to contain
G_verbose_message("some message here") calls in the code for --v to do
anything. That library function is very new (new for GRASS 6.3) so not
much uses it yet. There's an effort to move non-surprising status
messages to only show up in verbose mode, but it is early days for
that.
r.series works by row, then column, then by map. ie it works on all
maps at the same time (sorta) not sequentially. So G_percent() per row
is the best that can be done.
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.
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.
Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
1. Enter Rainer Krug and MapServer. I don't think my time frames allow for learning another software suite right now.
2. Use a script to build a .grc file with a group for gis.m. Before attempting this I would like to know if there are any limits to the number of layers that can be loaded.
3. Use r.patch to build one mosaic for each band. </snip>
Hamish wrote:
`<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.
`
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. [https://help.ubuntu.com/community/LinuxFilesystemsExplained](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?
I have 139 high resolution images, which I need to use as a background map
for some digitizing work. Loading 139x3 layers into gis.m is a real pain and
I can think of three workarounds.
3. Use r.patch to build one mosaic for each band.
I currently have r.patch running. It's been going for about 10.5hrs and has
reached 15%. Does this sound reasonable? I am starting to wonder if I'm
expecting too much. Here are my region settings:
How do the individual maps relate to the overall region?
If they are (approximately) tiles, I would suggest using a
hierarchical approach, patching groups of adjacent tiles into larger
tiles, then patching the larger tiles together, so that each r.patch
operation has relatively few maps, and the earlier stages have
relatively small regions.
The total time taken by r.patch is roughly proportional to the total
number of cells in the region multiplied by the number of input maps,
so the combination of a large region and a large number of maps will
be slow.
I have 139 high resolution images, which I need to use as a background map
for some digitizing work.
How do the individual maps relate to the overall region?
If they are (approximately) tiles, I would suggest using a
hierarchical approach, patching groups of adjacent tiles into larger
tiles, then patching the larger tiles together, so that each r.patch
operation has relatively few maps, and the earlier stages have
relatively small regions.
The total time taken by r.patch is roughly proportional to the total
number of cells in the region multiplied by the number of input maps,
so the combination of a large region and a large number of maps will
be slow.
Thanks for the advice Glynn. The images are tiles and the filenames follow a regular pattern, so I am able to patch blocks together quite easily with a simple script. I included lots of echos in the script and now I even have verbose messages
The script is running right now and making good progress...
