Swath profiles, although conceptually simple, are much less so to actually create. The underlying idea is, the standard line profiles of topography that we're used to just don't capture the greater landscape theme. What about regions just to the left of the profile? Or to the right? The line profile you have may deviate seriously from profiles generated there. So, the solution is to generate a line to profile, like you normally would, but this time to look off to either side, get all the elevation values out to a set distance that decently characterizes the adjacent area, and calculate some basic statistics on these values, for each point along your profile. The result is the minimum, mean, and maximum elevations off to each side, for each step along the profile line. When I calculated swath profiles for my undergraduate research, the method I followed was a fairly involved process: Get the elevation raster (DEM) into Arc GIS. Clip it to a smaller area that is easier to work with. Export it with a certain type of data format. Import it into Matlab, the same folder as the script. Figure out the script. There were actually two scripts that had to be used sequentially. Run the scripts. Tell the script which pixel to start the profile at, how long it was supposed to be, and how wide. Also type in the name of the file, the grid resolution, and a few other tidbits of menial info. Then Matlab sat and thought for a while. Then it output a graph showing min/mean/max elevation along the profile, and a picture of the profiled area. If it was too long, you had to re-run the script. And the most frustrating part was, the plan view picture of the swath couldn't easily be imported back into ArcGIS. You just had to look at it and estimate the boundaries by hand. Huh. Then, one day as I was exploring GRASS, I had a thought. The seemingly oddball v.mkgrid tool could generate a matrix of specified dimensions, including cell width, height, and orientation, and overlay it on your map. SO, if the matrix was a 1 x many cell array, with each cell as high as the known pixel resolution of the elevation raster I used, and cell width as wide as necessary to capture the surrounding topography, couldn't I use some sort of vector statistics tool to get min/mean/max elevation for each cell? Wouldn't that approximate a swath? It turns out that if you make a 1 x many dimensional grid with the v.mkgrid tool, you can interactively drape it in a preferred orientation and make the cells as short as one pixel in your DEM. Then, you can use the v.rast.stats tool to do exactly what I was hoping to do- calculate the min/mean/max/etc of whatever part of the raster (in this case, a DEM) the grid overlaid. Then, these statistical values could be distilled to the centroids of each cell. When I created the grid, I set the height of each cell. This is also the distance between centroids. The centroids, as a rule lie upon the same, grid-bisecting line in a 1 x many dimensional matrix. Hence, it's almost exactly the same idea of creating a transect line and getting statistical averages of elevation off to each side. Once the statistical values are put into the centroids, those centroids can be exported as a csv file, easily worked with in Excel, R, Matlab, Python, etc. You, too, can make a swath profile in GRASS GIS. Here is a link to my workflow: |

Geospatial processing > Geospatial tasks >