I’ve created a grass python script that generates a local relief model (LRM) from a high-resolution (such as from LIDAR) DEM based on Hesse, Ralf (2010): LiDAR-derived Local Relief Models - a new tool for archaeological prospection. Archaeological Prospection 17:67-72.
I’ve tested it on several data sets of mine and it seems to be working fine, however my data is limited to prehistoric Native American mounds. If anyone else has some data they can test the tool on and report on the results it would be much appreciated. The tool can be downloaded from https://github.com/egoddard/r.surf.lrm.
As a final note, I adapted this tool based on Rebecca Bennett’s bash script that was published in her dissertation. Thank you, Rebecca, for answering all of my questions and for your efforts in trying to test it out
actually I was working on the same module (named r.local.relief), so we have some duplication now. It is also based on [Hesse2010]. I was about to commit it to GRASS Addons but I need to write documentation first. For now, I’m adding the Python script into a attachment.
I’ve quickly tested both and they give slightly different results. The other visible difference is the contours-to-really_smooth_elevation step. It seems that usage of r.fillnuls is faster than v.surfs. But this might require more testing as well as the different results do (probably caused by different elevation reconstruction). We can talk about it off-list if you prefer or at least on grass-dev list. And of course, we should discuss some merge of our scripts.
As a side note I want also mention [r.shaded.pca] which I haven’t announced yet but which is already in addons. It is based on [Devereux2010].
Best,
Vaclav
[Hesse2010] Hesse, Ralf (2010): LiDAR-derived Local Relief Models - a new tool for archaeological prospection. Archaeological Prospection 17:67-72.
I’ve created a grass python script that generates a local relief model (LRM) from a high-resolution (such as from LIDAR) DEM based on Hesse, Ralf (2010): LiDAR-derived Local Relief Models - a new tool for archaeological prospection. Archaeological Prospection 17:67-72.
I’ve tested it on several data sets of mine and it seems to be working fine, however my data is limited to prehistoric Native American mounds. If anyone else has some data they can test the tool on and report on the results it would be much appreciated. The tool can be downloaded from https://github.com/egoddard/r.surf.lrm.
As a final note, I adapted this tool based on Rebecca Bennett’s bash script that was published in her dissertation. Thank you, Rebecca, for answering all of my questions and for your efforts in trying to test it out
actually I was working on the same module (named r.local.relief), so
we have some duplication now. It is also based on [Hesse2010]. I was
about to commit it to GRASS Addons but I need to write documentation
first. For now, I'm adding the Python script into a attachment. > >
I've quickly tested both and they give slightly different results. The
other visible difference is the contours-to-really_smooth_elevation
step.
Hi,
could you discuss the advantage of the local relief method? I take it that the idea is to remove the background signal to highlight local detail?
v.surf.rst or v.surf.bspline with a really big search window and loose tension might also be good for a smoothed backgroundto subtract away, and see also recent discussion about trying to get planar trend surfaces out of r.cog addon on the grass-dev ML (a work in progress).
Should fine relief be removed as well? (so gate filter and not just a low or high pass one)
It seems to me that the contouring step is needlessly lossy and artifact prone, and that you might get better results using the r.surf.contour module to recreate a raster from the contour lines. Or perhaps better use a {v,r}.random sampling technique as input to one of the v.surf spline modules or r.surf.nnbathy -- less artifacts than interpolating from contour lines. Also note that the contour method will flatten off the tops of features which are smaller than your contour step level. (so choice of contour step size becomes very important)
See also http://grasswiki.osgeo.org/wiki/Contour_lines_to_DEM
for an analysis and comparison of interpolation methods for creating surfaces from contour lines. (spoiler: the designed for the task r.surf.contour wins)
Paweł Netzel wrote an interesting script called r.elsamap:
r.elsamap creates raster layer (based on dtm nad slope). It creates
results similar to the results obtained form ELSAMAP method.
AFAIK based on:
Sasaki, H. and Mukoyama, S., 2007. The Development of ELSAMAP
(Elevation and Slope Angle Map) for Geographical Features
Interpretation. APA, 93, pp.8-16
I haven't been able to find solid information on how users who don't
compile themselves can install an addon that isn't available via
g.extension.
In general it's quite simple, users maintain a directory with all of
their executable scripts in it and before starting GRASS add
export GRASS_ADDON_PATH=/path/to/files
to their ~/.bashrc. (~/.grass.bashrc is no good, the variable has to
be set before grass starts)
Then it magically finds them. The g.extension module(s) just fits itself
into that and creates you an addon dir if one wasn't already set.
For scripts there is no other install or compiling needed, just put
it in a dir somewhere which is in the $PATH.
Python might be a problem, but if you just call your module by its full
name it should be ok (so with or without .py, just be sure to match
the exact filename).
The GRASS 6 make system is still missing build support for python
scripts (often it tries to reuse the shell Script.make, which mostly
works on Linux). Smooth building with correct .bat file wrappers
on Windows remains an issue. It can be done, I've seen it work, but
still needs a new PythonScript.make to work smoothly. (similarly user-
created personal shell scripts for GRASS 7 should have a ShellScript.make
to help folks who need that, even if there are none in the main release.)
Your script looks very nice (much cleaner than mine!). I definitely need to add some better error handling. I can see how using v.to.rast and r.fillnulls may introduce fewer artifacts than v.surf–looking forward to testing it. Based on the amount of helpful advice we’ve already received, I’m leaning towards grass-dev for discussing the best methods to use and merging of the scripts, but off-list is also ok.
actually I was working on the same module (named r.local.relief), so we have some duplication now. It is also based on [Hesse2010]. I was about to commit it to GRASS Addons but I need to write documentation first. For now, I’m adding the Python script into a attachment.
I’ve quickly tested both and they give slightly different results. The other visible difference is the contours-to-really_smooth_elevation step. It seems that usage of r.fillnuls is faster than v.surfs. But this might require more testing as well as the different results do (probably caused by different elevation reconstruction). We can talk about it off-list if you prefer or at least on grass-dev list. And of course, we should discuss some merge of our scripts.
As a side note I want also mention [r.shaded.pca] which I haven’t announced yet but which is already in addons. It is based on [Devereux2010].
Best,
Vaclav
[Hesse2010] Hesse, Ralf (2010): LiDAR-derived Local Relief Models - a new tool for archaeological prospection. Archaeological Prospection 17:67-72.
I’ve created a grass python script that generates a local relief model (LRM) from a high-resolution (such as from LIDAR) DEM based on Hesse, Ralf (2010): LiDAR-derived Local Relief Models - a new tool for archaeological prospection. Archaeological Prospection 17:67-72.
I’ve tested it on several data sets of mine and it seems to be working fine, however my data is limited to prehistoric Native American mounds. If anyone else has some data they can test the tool on and report on the results it would be much appreciated. The tool can be downloaded from https://github.com/egoddard/r.surf.lrm.
As a final note, I adapted this tool based on Rebecca Bennett’s bash script that was published in her dissertation. Thank you, Rebecca, for answering all of my questions and for your efforts in trying to test it out
To answer Hamish’s questions, here are some images (DEM+LRMs) of a smaller region in nc_spm. The idea is really to remove the overall main terrain features while small local differences are preserved.
For getting of the smooth terrain, random points and v.surf.rst or v.surf.bspline are probably good alternative. I had no chance to test various alternatives yet. I just tried smoothing + contours + r.fillnulls module and it worked so I staid with it.
The contours related (contour->dem) modules cannot be used since the contours are actually not contours of the elevation but of the first approximation of LRM. Than the values of elevation are assigned to the points/cells of contours.
As for the script installation, it would be nice to have direct installation form github.com, but this is really a grass-dev topic.
I haven’t been able to find solid information on how users who don’t
compile themselves can install an addon that isn’t available via
g.extension.
In general it’s quite simple, users maintain a directory with all of
their executable scripts in it and before starting GRASS add
export GRASS_ADDON_PATH=/path/to/files
to their ~/.bashrc. (~/.grass.bashrc is no good, the variable has to
be set before grass starts)
Then it magically finds them. The g.extension module(s) just fits itself
into that and creates you an addon dir if one wasn’t already set.
For scripts there is no other install or compiling needed, just put
it in a dir somewhere which is in the $PATH.
Python might be a problem, but if you just call your module by its full
name it should be ok (so with or without .py, just be sure to match
the exact filename).
The GRASS 6 make system is still missing build support for python
scripts (often it tries to reuse the shell Script.make, which mostly
works on Linux). Smooth building with correct .bat file wrappers
on Windows remains an issue. It can be done, I’ve seen it work, but
still needs a new PythonScript.make to work smoothly. (similarly user-
created personal shell scripts for GRASS 7 should have a ShellScript.make
to help folks who need that, even if there are none in the main release.)
On Thu, Sep 26, 2013 at 12:54 AM, Hamish <hamish_b@yahoo.com> wrote:
Vaclav wrote:
> Hi Eric,
>
> actually I was working on the same module (named r.local.relief), so
> we have some duplication now. It is also based on [Hesse2010]. I was
> about to commit it to GRASS Addons but I need to write documentation
> first. For now, I'm adding the Python script into a attachment. > >
> I've quickly tested both and they give slightly different results. The
> other visible difference is the contours-to-really_smooth_elevation
> step.
Hi,
could you discuss the advantage of the local relief method? I take it that
the idea is to remove the background signal to highlight local detail?
v.surf.rst or v.surf.bspline with a really big search window and loose
tension might also be good for a smoothed backgroundto subtract away, and
see also recent discussion about trying to get planar trend surfaces out of
r.cog addon on the grass-dev ML (a work in progress).
Should fine relief be removed as well? (so gate filter and not just a low
or high pass one)
It seems to me that the contouring step is needlessly lossy and artifact
prone, and that you might get better results using the r.surf.contour
module to recreate a raster from the contour lines. Or perhaps better use a
{v,r}.random sampling technique as input to one of the v.surf spline
modules or r.surf.nnbathy -- less artifacts than interpolating from contour
lines. Also note that the contour method will flatten off the tops of
features which are smaller than your contour step level. (so choice of
contour step size becomes very important)
The thought behind the contouring step is that when you apply a low pass
filter and subtract it from the DEM, the large scale features (based on the
selected kernel size) are eliminated and the small-scale features are
smoothed, resulting in bias toward small features and an underestimation of
the magnitude of the local relief elevations as the spatial extent of the
feature increases. By getting the 0-meter contours, converting them to
points, and getting the elevations of the original DEM for those points,
you're basically able to cut the large-scale features out of the original
DEM, leaving the local relief behind without smoothing.
See also http://grasswiki.osgeo.org/wiki/Contour_lines_to_DEM
for an analysis and comparison of interpolation methods for creating
surfaces from contour lines. (spoiler: the designed for the task
r.surf.contour wins)