[GRASSLIST:7755] Hutchinson's Adaptive Alogrithm for sound DEMs?

Hi all,

I am trying to create a DEM from Topographic
contours. I have been using regularized spline
with tension (v.surf.rst) and I am just not
content with the quality. My final objective is
to produce watersheds for sample locations using
"r.water.outlet". So I am looking for
alternatives and as aways preferabley something in
GRASS or at least GNU.

I was wondering if M.F. Hutchinson's alogrithm for
generating DEMs from his paper on the net "A
Locally Adaptive Approach to the Interprolation of
Digital Elevation Models"
(http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/papers/local.html)
has been written for GRASS or any other GNU program?.

It appears to be the algorithm that the CGIAR used
to re-grid the SRTM 90m DEM.

Thanks,

Phillip J. Allen
Consulting Geochemist
Lima Peru
e-mail: paallen@attglobal.net

Here a FWD from Helena Mitasova:

On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:

regarding watershed analysis, I had troubles getting watersheds using
r.water.outlet but I had excellent results for stream extraction and
watershed boundaries using r.watershed
for various types of DEMs including those interpolated using
s.surf.rst/v.surf.rst.

Mike's method is very good and I highly recommend it .
Spatially variable smoothing is already available in
s.surf.rst/v.surf.rst, we just did
not integrate its automated estimation based on slope because this is
very specific for contour data and there are many types of data
where adjusting smoothing as a function of
slope is not the best approach and can lead to the loss of features.
Original topogrid had serious problems with waves along contours and
this was an excellent
solution for the problem. From the email, it is not possible to tell
what quality problems
the user has and whether they can be fixed by tuning the parameters.
For example I noticed
that v.surf.rst had very low npmin default = 200 and a segmentation
update that we did for
s.surf.rst was not implemented. This should be fixed in 6.1

We are currently testing different interpolation methods including
topogrid (or whatever
its current name is) and v.surf.rst along with other methods and we
plan to implement modifications/improvements that we find beneficial.

I hope that this helps

Helena

>On Mon, Aug 01, 2005 at 08:06:21PM +0000, paallen@attglobal.net wrote:
>>Hi all,
>>
>>I am trying to create a DEM from Topographic
>>contours. I have been using regularized spline
>>with tension (v.surf.rst) and I am just not
>>content with the quality. My final objective is
>>to produce watersheds for sample locations using
>>"r.water.outlet". So I am looking for
>>alternatives and as aways preferabley something in
>>GRASS or at least GNU.
>>
>>I was wondering if M.F. Hutchinson's alogrithm for
>>generating DEMs from his paper on the net "A
>>Locally Adaptive Approach to the Interprolation of
>>Digital Elevation Models"
>>(http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/papers/local.html)
>>has been written for GRASS or any other GNU program?.
>>
>>It appears to be the algorithm that the CGIAR used
>>to re-grid the SRTM 90m DEM.
>>
>>
>>Thanks,
>>
>>Phillip J. Allen
>>Consulting Geochemist
>>Lima Peru
>>e-mail: paallen@attglobal.net
>>
>>
Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

Helena, Markus,

Since improving v.surf.rst is discussed, I would like to ad a few notes from
a simple user, who doesn't understand all the maths of DEM interpolation but
who would like to obtain decent results. Sorry for any naiveness. Please let
me know what you think and if any of my wishes you find worthy of adding to
v.surf.rst.

From: "Markus Neteler" <neteler@itc.it>

Here a FWD from Helena Mitasova:

On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:

We are currently testing different interpolation methods including
topogrid (or whatever its current name is)

I gues we should call it ANUDEM - after Hutchinson. The TOPOGRID is an
ArcInfo program, which is an implementation of ANUDEM v. 4.5 or 4.6.3,
depending ArcInfo/ArcGIS version
http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=20779.

and v.surf.rst along with other methods and we
plan to implement modifications/improvements that we find beneficial.

If I may point 4 features I find very usefull in ANUDEM (and two other
tools) for creating DEMs from data extracted from topo maps. It would be
great if v.surf.rst could provide them.

ANUDEM is able to utilize following data besides elevation points and
contours:

1. watercourses, including their flow direction
I used it in TOPOGRID. At little effort - only digitise the watercourses in
the direction needed - it is possible to obtain a DEM where the water flows exactly the way you want it.

2. elevation discontinuity lines, called 'cliffs' in ANUDEM
This was introduced in version 5.1. I haven't had an occasion to use it,
since it is not available in TOPOGRID and I never had the original ANUDEM at
hand. I only read it's supported in new version
http://cres.anu.edu.au/outputs/anudem.php and think it is a great feature.
Often elevation contour lines and points alone simply can't express all the
complexity of terrain when gullies, scarps, embakments, walls, other
breaklines are involved. That's due to these are not parallel to elevation
isolines, thus cannot be presented as elevation isolines. Trying to
represent them as points, although in theory doable in *some* cases, would
require a lot of work to digitise points dense enough and to correctly
estimate each point elevation manually. Yet utilising elevation
discontinuity lines, digitised from topo maps, could greatly improve DEM
accuracy - at very little effort. Especially in areas of land slides,
erosion drived by river or flooding, land deformation due to mining, cliff
shoreline - to name those I can think of right now.

Such a functionality is also present in SURGE interpolation software.
http://www.geocities.com/miroslavdressler/surgemain.htm
But it's only freeware/shareware for Windows, not free software, is very
limited as to amount of data it can handle in one turn and the input data
format is non standard and pretty complex.

3. waterbodies
I used it in TOPOGRID. The elevation of waterbodies interpolated agreed very
well with their actual elevation as seen on topo maps and they are flat like
they should be. I bet many folks would find it usefull for accurate
elevation representation in lakelands, visualisation of areas in the
vicinity of water bodies etc.

The other feature, not supported in ANUDEM but practical I think, are
ridges. I found it supported in another DEM interpolation software,
CatchmentSIM (again freeware for Windows, sigh), as "Interpolation Training
Lines". The user can digitise them from topo maps and inlude during
interpolation to model the mountain ridges in his DEM as he wishes
http://www.toolkit.net.au/catchsim/.

Maciek

Maciek and other GRASS users,

These are great points to consider. My work leads me into the realm of terrain analysis, so this topic is near and dear to me. I think that it would be great if the pooled efforts of the GRASS community could be used to make GRASS the premier DEM creation / modification environment. Since the quality of a DEM is of the utmost importance when calculating primary and secondary terrain parameters, documentation of and confidence in the algorithms used for DEM creation should be a priority.

Currently v.surf.rst provides a very flexible means to produce elevation surfaces from point and contour data. The recent work by Tomas Cebecauer and others (See "Processing digital terrain models by regularized spline with tension: tuning interpolation parameters for different input datasets" from the proceedings to the 2002 GRASS conference.) shows how v.surf.rst can be used in a method similar to ANUDEM to enforce proper drainage networks, by adding a "terrain skeleton".

In addition, in reference to a recent message from David Finlayson regarding cross-validation of v.surf.rst derrived data, it might be a good idea for someone with some experience doing so to make a how-to document. I for one am still a bit baffled at how to properly use the cross-validation tools in v.surf.rst.

Of course all of this is easy for me to say, and much harder to implement. As my C skills are not the best, perhaps I can contribute to this aspect of future work in the form of documentation...

Any thoughts, ideas from other users?

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

On Aug 14, 2005, at 12:03 PM, Maciek Sieczka wrote:

Helena, Markus,

Since improving v.surf.rst is discussed, I would like to ad a few notes from
a simple user, who doesn't understand all the maths of DEM interpolation but
who would like to obtain decent results. Sorry for any naiveness. Please let
me know what you think and if any of my wishes you find worthy of adding to
v.surf.rst.

From: "Markus Neteler" <neteler@itc.it>

Here a FWD from Helena Mitasova:

On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:

We are currently testing different interpolation methods including
topogrid (or whatever its current name is)

I gues we should call it ANUDEM - after Hutchinson. The TOPOGRID is an
ArcInfo program, which is an implementation of ANUDEM v. 4.5 or 4.6.3,
depending ArcInfo/ArcGIS version
http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=20779.

and v.surf.rst along with other methods and we
plan to implement modifications/improvements that we find beneficial.

If I may point 4 features I find very usefull in ANUDEM (and two other
tools) for creating DEMs from data extracted from topo maps. It would be
great if v.surf.rst could provide them.

ANUDEM is able to utilize following data besides elevation points and
contours:

1. watercourses, including their flow direction
I used it in TOPOGRID. At little effort - only digitise the watercourses in
the direction needed - it is possible to obtain a DEM where the water flows exactly the way you want it.

2. elevation discontinuity lines, called 'cliffs' in ANUDEM
This was introduced in version 5.1. I haven't had an occasion to use it,
since it is not available in TOPOGRID and I never had the original ANUDEM at
hand. I only read it's supported in new version
http://cres.anu.edu.au/outputs/anudem.php and think it is a great feature.
Often elevation contour lines and points alone simply can't express all the
complexity of terrain when gullies, scarps, embakments, walls, other
breaklines are involved. That's due to these are not parallel to elevation
isolines, thus cannot be presented as elevation isolines. Trying to
represent them as points, although in theory doable in *some* cases, would
require a lot of work to digitise points dense enough and to correctly
estimate each point elevation manually. Yet utilising elevation
discontinuity lines, digitised from topo maps, could greatly improve DEM
accuracy - at very little effort. Especially in areas of land slides,
erosion drived by river or flooding, land deformation due to mining, cliff
shoreline - to name those I can think of right now.

Such a functionality is also present in SURGE interpolation software.
http://www.geocities.com/miroslavdressler/surgemain.htm
But it's only freeware/shareware for Windows, not free software, is very
limited as to amount of data it can handle in one turn and the input data
format is non standard and pretty complex.

3. waterbodies
I used it in TOPOGRID. The elevation of waterbodies interpolated agreed very
well with their actual elevation as seen on topo maps and they are flat like
they should be. I bet many folks would find it usefull for accurate
elevation representation in lakelands, visualisation of areas in the
vicinity of water bodies etc.

The other feature, not supported in ANUDEM but practical I think, are
ridges. I found it supported in another DEM interpolation software,
CatchmentSIM (again freeware for Windows, sigh), as "Interpolation Training
Lines". The user can digitise them from topo maps and inlude during
interpolation to model the mountain ridges in his DEM as he wishes
http://www.toolkit.net.au/catchsim/.

Maciek

On Sun, 14 Aug 2005, Dylan Beaudette wrote:

Maciek and other GRASS users,

These are great points to consider. My work leads me into the realm of
terrain analysis, so this topic is near and dear to me. I think that it
would be great if the pooled efforts of the GRASS community could be
used to make GRASS the premier DEM creation / modification environment.
Since the quality of a DEM is of the utmost importance when calculating
primary and secondary terrain parameters, documentation of and
confidence in the algorithms used for DEM creation should be a
priority.

From my self-centered user perspective this is all a great idea :slight_smile:

(Even though lakes & rivers for breaklines do not really happen on the seabed
where I do most of my modelling :slight_smile:

I'd like to make more use of GRASS for this, but have found it slow &
cumbersome to the point of being unuseable when compared with GMT for
generating DEM's from point data (say 20 million points).

If anyone has any ideas on how to address this & tweak performance I'd be
grateful, or if there is any specific info I can provide to help in this
area?

A sort of "howto create a Spearfish-like DEM from raw point data" ??

Thanks

  Brent

I just want to echo my support of this. My colleagues and I are trying to to
model Holocene landforms in the Mediterranean, using DEM's created from
Terra ASTER imagery, along with ASTER and other satellite imagery, and
ground truthing. These kinds of additions to interpolation routines would be
very helpful.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Dylan Beaudette <dylan@iici.no-ip.org>
Date: Sun, 14 Aug 2005 20:51:34 -0700
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASSLIST:7897] Re: Hutchinson's Adaptive Alogrithm for sound DEMs?

Maciek and other GRASS users,

These are great points to consider. My work leads me into the realm of
terrain analysis, so this topic is near and dear to me. I think that it
would be great if the pooled efforts of the GRASS community could be
used to make GRASS the premier DEM creation / modification environment.
Since the quality of a DEM is of the utmost importance when calculating
primary and secondary terrain parameters, documentation of and
confidence in the algorithms used for DEM creation should be a
priority.

Currently v.surf.rst provides a very flexible means to produce
elevation surfaces from point and contour data. The recent work by
Tomas Cebecauer and others (See "Processing digital terrain models by
regularized spline with tension: tuning interpolation parameters for
different input datasets" from the proceedings to the 2002 GRASS
conference.) shows how v.surf.rst can be used in a method similar to
ANUDEM to enforce proper drainage networks, by adding a "terrain
skeleton".

In addition, in reference to a recent message from David Finlayson
regarding cross-validation of v.surf.rst derrived data, it might be a
good idea for someone with some experience doing so to make a how-to
document. I for one am still a bit baffled at how to properly use the
cross-validation tools in v.surf.rst.

Of course all of this is easy for me to say, and much harder to
implement. As my C skills are not the best, perhaps I can contribute
to this aspect of future work in the form of documentation...

Any thoughts, ideas from other users?

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

On Aug 14, 2005, at 12:03 PM, Maciek Sieczka wrote:

Helena, Markus,

Since improving v.surf.rst is discussed, I would like to ad a few
notes from
a simple user, who doesn't understand all the maths of DEM
interpolation but
who would like to obtain decent results. Sorry for any naiveness.
Please let
me know what you think and if any of my wishes you find worthy of
adding to
v.surf.rst.

From: "Markus Neteler" <neteler@itc.it>

Here a FWD from Helena Mitasova:

On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:

We are currently testing different interpolation methods including
topogrid (or whatever its current name is)

I gues we should call it ANUDEM - after Hutchinson. The TOPOGRID is an
ArcInfo program, which is an implementation of ANUDEM v. 4.5 or 4.6.3,
depending ArcInfo/ArcGIS version
http://support.esri.com/index.cfm?
fa=knowledgebase.techarticles.articleShow&d=20779.

and v.surf.rst along with other methods and we
plan to implement modifications/improvements that we find beneficial.

If I may point 4 features I find very usefull in ANUDEM (and two other
tools) for creating DEMs from data extracted from topo maps. It would
be
great if v.surf.rst could provide them.

ANUDEM is able to utilize following data besides elevation points and
contours:

1. watercourses, including their flow direction
I used it in TOPOGRID. At little effort - only digitise the
watercourses in
the direction needed - it is possible to obtain a DEM where the water
flows exactly the way you want it.

2. elevation discontinuity lines, called 'cliffs' in ANUDEM
This was introduced in version 5.1. I haven't had an occasion to use
it,
since it is not available in TOPOGRID and I never had the original
ANUDEM at
hand. I only read it's supported in new version
http://cres.anu.edu.au/outputs/anudem.php and think it is a great
feature.
Often elevation contour lines and points alone simply can't express
all the
complexity of terrain when gullies, scarps, embakments, walls, other
breaklines are involved. That's due to these are not parallel to
elevation
isolines, thus cannot be presented as elevation isolines. Trying to
represent them as points, although in theory doable in *some* cases,
would
require a lot of work to digitise points dense enough and to correctly
estimate each point elevation manually. Yet utilising elevation
discontinuity lines, digitised from topo maps, could greatly improve
DEM
accuracy - at very little effort. Especially in areas of land slides,
erosion drived by river or flooding, land deformation due to mining,
cliff
shoreline - to name those I can think of right now.

Such a functionality is also present in SURGE interpolation software.
http://www.geocities.com/miroslavdressler/surgemain.htm
But it's only freeware/shareware for Windows, not free software, is
very
limited as to amount of data it can handle in one turn and the input
data
format is non standard and pretty complex.

3. waterbodies
I used it in TOPOGRID. The elevation of waterbodies interpolated
agreed very
well with their actual elevation as seen on topo maps and they are
flat like
they should be. I bet many folks would find it usefull for accurate
elevation representation in lakelands, visualisation of areas in the
vicinity of water bodies etc.

The other feature, not supported in ANUDEM but practical I think, are
ridges. I found it supported in another DEM interpolation software,
CatchmentSIM (again freeware for Windows, sigh), as "Interpolation
Training
Lines". The user can digitise them from topo maps and inlude during
interpolation to model the mountain ridges in his DEM as he wishes
http://www.toolkit.net.au/catchsim/.

Maciek

Hi,

when I was working on my master thesis, I was also using v.surf.rst
and was satisfied with its speed. On 5100 Bobomips machine I got about
130 points/sec. I played a lot with segmax and other parameters until
I was satisfied with results and speed.

Only easy way to speed it up would be using parallel processing. If
task could be split into multiple processes, then for large data sets
some OpenMOSIX type clusters could be used. That's would be more
important than minimal speedup for single-processor PCs.

just my 2c.

Maris.

2005/8/15, Brent Wood <b.wood@niwa.co.nz>:

On Sun, 14 Aug 2005, Dylan Beaudette wrote:

> Maciek and other GRASS users,
>
> These are great points to consider. My work leads me into the realm of
> terrain analysis, so this topic is near and dear to me. I think that it
> would be great if the pooled efforts of the GRASS community could be
> used to make GRASS the premier DEM creation / modification environment.
> Since the quality of a DEM is of the utmost importance when calculating
> primary and secondary terrain parameters, documentation of and
> confidence in the algorithms used for DEM creation should be a
> priority.

>From my self-centered user perspective this is all a great idea :slight_smile:

(Even though lakes & rivers for breaklines do not really happen on the seabed
where I do most of my modelling :slight_smile:

I'd like to make more use of GRASS for this, but have found it slow &
cumbersome to the point of being unuseable when compared with GMT for
generating DEM's from point data (say 20 million points).

If anyone has any ideas on how to address this & tweak performance I'd be
grateful, or if there is any specific info I can provide to help in this
area?

A sort of "howto create a Spearfish-like DEM from raw point data" ??

Thanks

  Brent

Regarding this discussion on which features GRASS should have for
DEM/surface creation, I'd like to give my two cents and add one more
to the list, that is the possibility of using fault lines. This is not
so useful for general terrain analysis, but if one wants to
interpolate a stratigraphic level, for instance, it really makes a
difference.
There are several proprietary software that does it (eg, Surfer), you
give a vector file of fault lines as a secondary input of data points
for interpolation, and the mathematical function will understand the
lines as "barriers", that is, values in one side of a line won't be
taken into account when calculating interpolated values on the other
side of the line.

Carlos

On 8/14/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

Helena, Markus,

Since improving v.surf.rst is discussed, I would like to ad a few notes from
a simple user, who doesn't understand all the maths of DEM interpolation but
who would like to obtain decent results. Sorry for any naiveness. Please let
me know what you think and if any of my wishes you find worthy of adding to
v.surf.rst.

From: "Markus Neteler" <neteler@itc.it>

> Here a FWD from Helena Mitasova:
>
> On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:

>> We are currently testing different interpolation methods including
>> topogrid (or whatever its current name is)

I gues we should call it ANUDEM - after Hutchinson. The TOPOGRID is an
ArcInfo program, which is an implementation of ANUDEM v. 4.5 or 4.6.3,
depending ArcInfo/ArcGIS version
http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=20779.

>> and v.surf.rst along with other methods and we
>> plan to implement modifications/improvements that we find beneficial.

If I may point 4 features I find very usefull in ANUDEM (and two other
tools) for creating DEMs from data extracted from topo maps. It would be
great if v.surf.rst could provide them.

ANUDEM is able to utilize following data besides elevation points and
contours:

1. watercourses, including their flow direction
I used it in TOPOGRID. At little effort - only digitise the watercourses in
the direction needed - it is possible to obtain a DEM where the water flows
exactly the way you want it.

2. elevation discontinuity lines, called 'cliffs' in ANUDEM
This was introduced in version 5.1. I haven't had an occasion to use it,
since it is not available in TOPOGRID and I never had the original ANUDEM at
hand. I only read it's supported in new version
http://cres.anu.edu.au/outputs/anudem.php and think it is a great feature.
Often elevation contour lines and points alone simply can't express all the
complexity of terrain when gullies, scarps, embakments, walls, other
breaklines are involved. That's due to these are not parallel to elevation
isolines, thus cannot be presented as elevation isolines. Trying to
represent them as points, although in theory doable in *some* cases, would
require a lot of work to digitise points dense enough and to correctly
estimate each point elevation manually. Yet utilising elevation
discontinuity lines, digitised from topo maps, could greatly improve DEM
accuracy - at very little effort. Especially in areas of land slides,
erosion drived by river or flooding, land deformation due to mining, cliff
shoreline - to name those I can think of right now.

Such a functionality is also present in SURGE interpolation software.
http://www.geocities.com/miroslavdressler/surgemain.htm
But it's only freeware/shareware for Windows, not free software, is very
limited as to amount of data it can handle in one turn and the input data
format is non standard and pretty complex.

3. waterbodies
I used it in TOPOGRID. The elevation of waterbodies interpolated agreed very
well with their actual elevation as seen on topo maps and they are flat like
they should be. I bet many folks would find it usefull for accurate
elevation representation in lakelands, visualisation of areas in the
vicinity of water bodies etc.

The other feature, not supported in ANUDEM but practical I think, are
ridges. I found it supported in another DEM interpolation software,
CatchmentSIM (again freeware for Windows, sigh), as "Interpolation Training
Lines". The user can digitise them from topo maps and inlude during
interpolation to model the mountain ridges in his DEM as he wishes
http://www.toolkit.net.au/catchsim/.

Maciek

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+

Michael Barton wrote:

I just want to echo my support of this. My colleagues and I are trying to to
model Holocene landforms in the Mediterranean, using DEM's created from
Terra ASTER imagery, along with ASTER and other satellite imagery, and
ground truthing. These kinds of additions to interpolation routines would be
very helpful.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Dylan Beaudette <dylan@iici.no-ip.org>
Date: Sun, 14 Aug 2005 20:51:34 -0700
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASSLIST:7897] Re: Hutchinson's Adaptive Alogrithm for sound DEMs?

Maciek and other GRASS users,

These are great points to consider. My work leads me into the realm of
terrain analysis, so this topic is near and dear to me. I think that it
would be great if the pooled efforts of the GRASS community could be
used to make GRASS the premier DEM creation / modification environment.
Since the quality of a DEM is of the utmost importance when calculating
primary and secondary terrain parameters, documentation of and
confidence in the algorithms used for DEM creation should be a
priority.

Currently v.surf.rst provides a very flexible means to produce
elevation surfaces from point and contour data. The recent work by
Tomas Cebecauer and others (See "Processing digital terrain models by
regularized spline with tension: tuning interpolation parameters for
different input datasets" from the proceedings to the 2002 GRASS
conference.) shows how v.surf.rst can be used in a method similar to
ANUDEM to enforce proper drainage networks, by adding a "terrain
skeleton".

In addition, in reference to a recent message from David Finlayson
regarding cross-validation of v.surf.rst derrived data, it might be a
good idea for someone with some experience doing so to make a how-to
document. I for one am still a bit baffled at how to properly use the
cross-validation tools in v.surf.rst.

Of course all of this is easy for me to say, and much harder to
implement. As my C skills are not the best, perhaps I can contribute
to this aspect of future work in the form of documentation...

Any thoughts, ideas from other users?

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

On Aug 14, 2005, at 12:03 PM, Maciek Sieczka wrote:

Helena, Markus,

Since improving v.surf.rst is discussed, I would like to ad a few
notes from
a simple user, who doesn't understand all the maths of DEM
interpolation but
who would like to obtain decent results. Sorry for any naiveness.
Please let
me know what you think and if any of my wishes you find worthy of
adding to
v.surf.rst.

From: "Markus Neteler" <neteler@itc.it>

Here a FWD from Helena Mitasova:

On Tue, Aug 02, 2005 at 07:01:33PM -0400, Helena Mitasova wrote:
       

We are currently testing different interpolation methods including
topogrid (or whatever its current name is)
         

I gues we should call it ANUDEM - after Hutchinson. The TOPOGRID is an
ArcInfo program, which is an implementation of ANUDEM v. 4.5 or 4.6.3,
depending ArcInfo/ArcGIS version
http://support.esri.com/index.cfm?
fa=knowledgebase.techarticles.articleShow&d=20779.

and v.surf.rst along with other methods and we
plan to implement modifications/improvements that we find beneficial.
         

If I may point 4 features I find very usefull in ANUDEM (and two other
tools) for creating DEMs from data extracted from topo maps. It would
be
great if v.surf.rst could provide them.

ANUDEM is able to utilize following data besides elevation points and
contours:

1. watercourses, including their flow direction
I used it in TOPOGRID. At little effort - only digitise the
watercourses in
the direction needed - it is possible to obtain a DEM where the water
flows exactly the way you want it.

2. elevation discontinuity lines, called 'cliffs' in ANUDEM
This was introduced in version 5.1. I haven't had an occasion to use
it,
since it is not available in TOPOGRID and I never had the original
ANUDEM at
hand. I only read it's supported in new version
http://cres.anu.edu.au/outputs/anudem.php and think it is a great
feature.
Often elevation contour lines and points alone simply can't express
all the
complexity of terrain when gullies, scarps, embakments, walls, other
breaklines are involved. That's due to these are not parallel to
elevation
isolines, thus cannot be presented as elevation isolines. Trying to
represent them as points, although in theory doable in *some* cases,
would
require a lot of work to digitise points dense enough and to correctly
estimate each point elevation manually. Yet utilising elevation
discontinuity lines, digitised from topo maps, could greatly improve
DEM
accuracy - at very little effort. Especially in areas of land slides,
erosion drived by river or flooding, land deformation due to mining,
cliff
shoreline - to name those I can think of right now.

Such a functionality is also present in SURGE interpolation software.
http://www.geocities.com/miroslavdressler/surgemain.htm
But it's only freeware/shareware for Windows, not free software, is
very
limited as to amount of data it can handle in one turn and the input
data
format is non standard and pretty complex.

3. waterbodies
I used it in TOPOGRID. The elevation of waterbodies interpolated
agreed very
well with their actual elevation as seen on topo maps and they are
flat like
they should be. I bet many folks would find it usefull for accurate
elevation representation in lakelands, visualisation of areas in the
vicinity of water bodies etc.

The other feature, not supported in ANUDEM but practical I think, are
ridges. I found it supported in another DEM interpolation software,
CatchmentSIM (again freeware for Windows, sigh), as "Interpolation
Training
Lines". The user can digitise them from topo maps and inlude during
interpolation to model the mountain ridges in his DEM as he wishes
http://www.toolkit.net.au/catchsim/.

Maciek

If the subject is DEM. I can offer some:

1. Kriging interpolation in Grass to create DEM might be an idea.
(using R in grass requires a big computer memory and long time)
2. Since it is the mother of some maps, DEM is a crucial thing in GIS
applications. Any document list related with DEM may be useful.

regards

Ahmet Temiz
geologist
Earthquake Research Department
TURKEY

______________________________________
XamimeLT - installed on mailserver for domain @deprem.gov.tr
Queries to: postmaster@deprem.gov.tr
______________________________________
The views and opinions expressed in this e-mail message are the sender's own
and do not necessarily represent the views and the opinions of Earthquake Research Dept.
of General Directorate of Disaster Affairs.

Bu e-postadaki fikir ve gorusler gonderenin sahsina ait olup, yasal olarak T.C.
B.I.B. Afet Isleri Gn.Mud. Deprem Arastirma Dairesi'ni baglayici nitelikte degildir.

On Sunday 14 August 2005 09:42 pm, Brent Wood wrote:
[snip]

(Even though lakes & rivers for breaklines do not really happen on the
seabed where I do most of my modelling :slight_smile:

I'd like to make more use of GRASS for this, but have found it slow &
cumbersome to the point of being unuseable when compared with GMT for
generating DEM's from point data (say 20 million points).

Brent how does the gridding procedure in GMT compare to v.surf.rst ? is speed
being gained over loss in accuracy or flexibility?

If anyone has any ideas on how to address this & tweak performance I'd be
grateful, or if there is any specific info I can provide to help in this
area?

there are some nice papers on tweaking the parameters for v.surf.rst and its
kin in the recent GRASS 2002 conference proceedings [1].

A sort of "howto create a Spearfish-like DEM from raw point data" ??

Again, one of Helena's papers talks about how to do this, and can be found on
her website [2] (i have the relevant PDF if you would like it, but i
originally found it here).

1. http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/home.html
2. http://skagit.meas.ncsu.edu/~helena/gmslab/index.html

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Dylan Beaudette wrote:

I'd like to make more use of GRASS for this, but have found it slow &
cumbersome to the point of being unuseable when compared with GMT for
generating DEM's from point data (say 20 million points).

Brent how does the gridding procedure in GMT compare to v.surf.rst ? is speed being gained over loss in accuracy or flexibility?

And I am wondering does GMT actually output the grid to a non-GMT readable format - or does it just use it in the rendering process and toss it away.

Tyler

On Mon, 15 Aug 2005, Dylan Beaudette wrote:

On Sunday 14 August 2005 09:42 pm, Brent Wood wrote:
[snip]
> (Even though lakes & rivers for breaklines do not really happen on the
> seabed where I do most of my modelling :slight_smile:
>
> I'd like to make more use of GRASS for this, but have found it slow &
> cumbersome to the point of being unuseable when compared with GMT for
> generating DEM's from point data (say 20 million points).

Brent how does the gridding procedure in GMT compare to v.surf.rst ? is speed
being gained over loss in accuracy or flexibility?

Um. A few notes.

GMT supports blockmean/blockmedian/blockmode for pre-processing lists of
XYZ points to "fit" the grid before trying to grid the data. This can
dramatically reduce the number of points to grid.

For some of my work with commercial fishing catch/effort data, generating
a grid based on the sum of values per grid cell is useful, and can be done
with blockmean (a parameter prevents dividing sum by count in the output.
Very useful :slight_smile:

GMT uses "surface" (& a couple of other commands as well, but I find this
works for me. I may need to tweak the tension parameter depending on my
data, but around 0.7 usually seems close)

see:
http://gmt.soest.hawaii.edu/gmt/doc/html/surface.html
http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node111.html#15221

Given the code is available, it may be feasible to port surface/blockmean
etc to GRASS? Need to ask a programmer :slight_smile:

FWIW I also got very robust & fast results using the minc (minimum-curvature)
command of the commercial GIS package Genamap. It was an implementation of
the algorithm described in:
Webring, M., 1981, MINC: A gridding program based on minimum curvature: U.
S. Geological Survey Open-File report 81-1224.

As I now only use OS tools, I don't have access to this any more :slight_smile:

> If anyone has any ideas on how to address this & tweak performance I'd be
> grateful, or if there is any specific info I can provide to help in this
> area?

there are some nice papers on tweaking the parameters for v.surf.rst and its
kin in the recent GRASS 2002 conference proceedings [1].

> A sort of "howto create a Spearfish-like DEM from raw point data" ??

Again, one of Helena's papers talks about how to do this, and can be found on
her website [2] (i have the relevant PDF if you would like it, but i
originally found it here).

Yep. I have these, but still had problems with performance. One of the
issues was that generating a GRASS vector (point) dataset with all the
source data was slow & cumbersome, with the indices occupying much more
space than the data. I did get some suggestions from this list over that,
basically saying yes, that's it right now... so I stuck with GMT. I have
imported the GMT grids into GRASS to use with Nviz, with limited success,
the limits probably more due to the amount of time I spent than GRASS
itself.

(To be fair I must point out that I have basically dabbled in GRASS over
the years, rather than used it in earnest. My data is generally vector
based & GRASS has not always been an effective vector GIS. I do plan to
revisit GRASS/PostGIS/QGIS/R again.... But as GMT has worked well, with
GDAL/OGR etc, GRASS has not been a priority for me. Maybe when time
permits, sigh... :slight_smile:

1. http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/home.html
2. http://skagit.meas.ncsu.edu/~helena/gmslab/index.html

Thanks for the suggestions. DEM generation is an area of ongoing interest
& GRASS is _almost_ a useful tool for me in this. I'd love to see it
improved and become the DEM generating standard.

Thanks,

  Brent