View source for Working with many rasters

'''Q:''' I have a great number of aerial images I need to use as a background map for some digitizing work. What can I do to ease the pain of working with this large dataset?

'''A:''' The pain you are experiencing probably arises from trying to figure out which map to activate when you zoom in and doing this many times. You have at least three options available to you.

; 1. Use a Web Map Server (WMS)
: WMS is normally used for fetching remote maps, but could be used on the local host to simplify the task of working with many map tiles. You would simply provide the bounding box and resolution of your desired region and the server would select and return the correct tiles. Since the data is imported into GRASS the data store would grow as you panned and zoomed. This could be avoided by using the same filename for each import and overwriting the GRASS raster. There may be negative performance considerations with this approach.

; 2. Use the group functionality of gis.m
: The map tiles could be loaded into one or more groups in the GIS Manager (gis.m). Using the gui to load the maps can be tedious with a large number of maps and especially if the maps have three bands because each band is a separate file that must be loaded. The workspace file (.grc) which holds details of the loaded groups and layers is a text file and so a script could be used to build this file.

; 3. Patch your tiles together
: The map tiles could be patched into one or more mosaics with due consideration for the maximum file sizes permissible on your operating system and filesystem. For patching raster maps r.patch is your friend. Glynn Clements made the following remarks on the mailing list regarding the use of r.patch on a large region:

: "If they [the maps] 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."

: Patching a large region can take several days and with many calls to r.patch a simple script becomes necessary. You may wish to request verbose output from r.patch and include some echos in your script so you can keep a check on the progress.

[[Category:FAQ]]