Hi all,
is it possible in GRASS to perform something similar to "Topo to
Raster" as known in ArcGIS [1]?
Thanks in advance, Martin
[1] http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000007m000000.htm
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi.
is it possible in GRASS to perform something similar to "Topo to
Raster" as known in ArcGIS [1]?[1]
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000007m000000.htm
Are there specific inputs of the "topo to raster" tool that are of
importance for your application?
Using contour lines as input, I have found the r.surf.nnbathy module to
perform very well. For (LiDAR) point data, my preference is v.surf.rst.
The "topo to raster" tool alters the DEM by filling sinks. The arcgis
approach alters the DEM so that their flow routing tool doesnt stop in
every sink. My preference is to use the data as close to original source
as possible, and let the superb GRASS flow and routing algorithms handle
routing through the sinks automatically.
If one wanted to mimic the arcgis method of filling sinks after
interpolating, one could run iterations of r.fill.dir to make it
depression-less. This isnt necessary with the hydrologic tools in GRASS
because the r.watershed algorithm is intelligent enough to keep seeking the
next lowest location the DEM. Add in the fact that r.watershed has MFD,
and GRASS quickly surpasses the ESRI hydrologic toolset offerings.
HTH,
Mark
On Tue, Mar 4, 2014 at 7:25 PM, Mark Seibel <mseibel@gmail.com> wrote:
Hi.
is it possible in GRASS to perform something similar to "Topo to
Raster" as known in ArcGIS [1]?[1]
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000007m000000.htmAre there specific inputs of the "topo to raster" tool that are of
importance for your application?Using contour lines as input, I have found the r.surf.nnbathy module to
perform very well.
Previously, contour lines created by land surveying provided more
detail than available DEMs. Nowadays (since SRTM of 2001), DEMs
provide more detail than contour lines and contour lines are usually
derived from a DEM. Therefore creating a DEM from contour lines which
if in doubt have been created using a DEM is no longer recommended,
rather use any DEM instead.
For (LiDAR) point data, my preference is v.surf.rst.
The "topo to raster" tool alters the DEM by filling sinks.
The ArcGIS reference for sink filling is Goodchild and Mark (1987).
ArcGIS thus ignores the literature of the last 27 years. According to
the ArcGIS documentation, "The program assumes that all unidentified
sinks are errors". Identified sinks are those supplied by the user.
Unfortunately for ArcGIS, unidentified sinks are not errors but
usually true terrain elevation, particularly in the year 1987 when
LIDAR was not yet available and DEMs were derived from radar. That
means that the elevation values surrounding sinks are erroneuos rather
than the sinks themselves. Two (of several) methods to deal with sinks
in a more realistic way are the minimum impact approach of Lindsay &
Creed (2005) which alters the DEM (implemented in GRASS as r.hydrodem)
and r.watershed which does not alter the DEM.
In short, you should not use ArcGIS to perform hydrological analysis
or create a DEM for hydrological analysis because the ESRI tools use
methods from the 1980's. Doing something similar to "Topo to Raster"
as known in ArcGIS does not make sense. Rather use
RiverTools/Whitebox/TauDEM/GRASS.
Markus M
The arcgis
approach alters the DEM so that their flow routing tool doesnt stop in every
sink. My preference is to use the data as close to original source as
possible, and let the superb GRASS flow and routing algorithms handle
routing through the sinks automatically.If one wanted to mimic the arcgis method of filling sinks after
interpolating, one could run iterations of r.fill.dir to make it
depression-less. This isnt necessary with the hydrologic tools in GRASS
because the r.watershed algorithm is intelligent enough to keep seeking the
next lowest location the DEM. Add in the fact that r.watershed has MFD, and
GRASS quickly surpasses the ESRI hydrologic toolset offerings.HTH,
Mark_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hi.
> Using contour lines as input, I have found the r.surf.nnbathy module to
> perform very well.Previously, contour lines created by land surveying provided more
detail than available DEMs. Nowadays (since SRTM of 2001), DEMs
provide more detail than contour lines and contour lines are usually
derived from a DEM. Therefore creating a DEM from contour lines which
if in doubt have been created using a DEM is no longer recommended,
rather use any DEM instead.
I certainly agree that contour lines are poor quality input data, however,
for situations involving conceptual reclamation, contours are used to build
the post-development DEM. This still allows for (albeit generalized)
conceptual modeling of the drainage areas for reclaimed streams and
drainage areas, and allows for pre/post development analysis of drainage
areas (as it is understood the contours are conceptual, not as-built).
Nice to know that GRASS has modules that can cope with contour data, and
still produce adequate and reliable results.
Mark
These things are nice to hear, however I was trying to read about that in r.hydrodem manual but it is just confusing in what is similar to what in implementation or results and does not give any overview if you don’t know the referenced modules. This reminds me about the request here on the mailing list to create some guidelines or tutorial about which water modules should be used when.
Maybe, some pictures would be helpful. r.slope.aspect has the detailed pictures with numbers, this is nice. Do we have date for in NC sample dataset? What about adding some images to manual during Vienna community sprint? This is the thing which can be done remotely by any GRASS user and than just committed by some developer.
Vaclav
http://grass.osgeo.org/grass70/manuals/addons/r.hydrodem.html
http://grass.osgeo.org/grass70/manuals/r.slope.aspect.html
On Tue, Mar 4, 2014 at 3:59 PM, Mark Seibel <mseibel@gmail.com> wrote:
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hi.
Using contour lines as input, I have found the r.surf.nnbathy module to
perform very well.Previously, contour lines created by land surveying provided more
detail than available DEMs. Nowadays (since SRTM of 2001), DEMs
provide more detail than contour lines and contour lines are usually
derived from a DEM. Therefore creating a DEM from contour lines which
if in doubt have been created using a DEM is no longer recommended,
rather use any DEM instead.
I certainly agree that contour lines are poor quality input data, however, for situations involving conceptual reclamation, contours are used to build the post-development DEM. This still allows for (albeit generalized) conceptual modeling of the drainage areas for reclaimed streams and drainage areas, and allows for pre/post development analysis of drainage areas (as it is understood the contours are conceptual, not as-built). Nice to know that GRASS has modules that can cope with contour data, and still produce adequate and reliable results.
Mark
Hi,
2014-03-04 19:25 GMT+01:00 Mark Seibel <mseibel@gmail.com>:
Are there specific inputs of the "topo to raster" tool that are of
importance for your application?
not really I just want to show my students that almost everything what
they are doing in the class using ArcGIS they can do using open source
GRASS GIS quite easily 
Using contour lines as input, I have found the r.surf.nnbathy module to
perform very well. For (LiDAR) point data, my preference is v.surf.rst.
Right, `r.surf.nnbathy` is based on Pavel Sakov's nn natural neighbor
interpolation library. This library is provided in MIT licence. Then
we could probably incorporate it into main GRASS source code, right? I
found code in Addons [1], btw, link at [2] doesn't work. The module is
written as a bash script and needs to be ported to Python for G7.
What do you think?
If one wanted to mimic the arcgis method of filling sinks after
interpolating, one could run iterations of r.fill.dir to make it
depression-less. This isnt necessary with the hydrologic tools in GRASS
because the r.watershed algorithm is intelligent enough to keep seeking the
next lowest location the DEM. Add in the fact that r.watershed has MFD, and
GRASS quickly surpasses the ESRI hydrologic toolset offerings.
Thanks for clarification.
Martin
[1] http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.surf.nnbathy/r.surf.nnbathy
[2] http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.surf.nnbathy
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
the notes bellow would make sense to put on the wiki, where it should go? Martin
2014-03-04 21:34 GMT+01:00 Markus Metz <markus.metz.giswork@gmail.com>:
On Tue, Mar 4, 2014 at 7:25 PM, Mark Seibel <mseibel@gmail.com> wrote:
Hi.
is it possible in GRASS to perform something similar to "Topo to
Raster" as known in ArcGIS [1]?[1]
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000007m000000.htmAre there specific inputs of the "topo to raster" tool that are of
importance for your application?Using contour lines as input, I have found the r.surf.nnbathy module to
perform very well.Previously, contour lines created by land surveying provided more
detail than available DEMs. Nowadays (since SRTM of 2001), DEMs
provide more detail than contour lines and contour lines are usually
derived from a DEM. Therefore creating a DEM from contour lines which
if in doubt have been created using a DEM is no longer recommended,
rather use any DEM instead.For (LiDAR) point data, my preference is v.surf.rst.
The "topo to raster" tool alters the DEM by filling sinks.The ArcGIS reference for sink filling is Goodchild and Mark (1987).
ArcGIS thus ignores the literature of the last 27 years. According to
the ArcGIS documentation, "The program assumes that all unidentified
sinks are errors". Identified sinks are those supplied by the user.
Unfortunately for ArcGIS, unidentified sinks are not errors but
usually true terrain elevation, particularly in the year 1987 when
LIDAR was not yet available and DEMs were derived from radar. That
means that the elevation values surrounding sinks are erroneuos rather
than the sinks themselves. Two (of several) methods to deal with sinks
in a more realistic way are the minimum impact approach of Lindsay &
Creed (2005) which alters the DEM (implemented in GRASS as r.hydrodem)
and r.watershed which does not alter the DEM.In short, you should not use ArcGIS to perform hydrological analysis
or create a DEM for hydrological analysis because the ESRI tools use
methods from the 1980's. Doing something similar to "Topo to Raster"
as known in ArcGIS does not make sense. Rather use
RiverTools/Whitebox/TauDEM/GRASS.Markus M
The arcgis
approach alters the DEM so that their flow routing tool doesnt stop in every
sink. My preference is to use the data as close to original source as
possible, and let the superb GRASS flow and routing algorithms handle
routing through the sinks automatically.If one wanted to mimic the arcgis method of filling sinks after
interpolating, one could run iterations of r.fill.dir to make it
depression-less. This isnt necessary with the hydrologic tools in GRASS
because the r.watershed algorithm is intelligent enough to keep seeking the
next lowest location the DEM. Add in the fact that r.watershed has MFD, and
GRASS quickly surpasses the ESRI hydrologic toolset offerings.HTH,
Mark_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-03-05 2:46 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:
Maybe, some pictures would be helpful. r.slope.aspect has the detailed
pictures with numbers, this is nice. Do we have date for in NC sample
dataset? What about adding some images to manual during Vienna community
sprint? This is the thing which can be done remotely by any GRASS user and
than just committed by some developer.Vaclav
http://grass.osgeo.org/grass70/manuals/addons/r.hydrodem.html
http://grass.osgeo.org/grass70/manuals/r.slope.aspect.html
right, the manual of r.hydrodem should be improved, we can start with
notes which wrote MM to the ML. Any volunteer? Martin
Hi,
2014-04-01 12:37 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
Right, `r.surf.nnbathy` is based on Pavel Sakov's nn natural neighbor
interpolation library. This library is provided in MIT licence. Then
we could probably incorporate it into main GRASS source code, right? I
ah, nn-c is based on triangle library. But probably it wouldn't be so
difficult to replace this part with GRASS triangulation code or other
libraries like CGAL or so, any opinion? Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
W dniu 01.04.2014 12:37, Martin Landa pisze:
found code in Addons [1], btw, link at [2] doesn't work
Corrected that.
[1] http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.surf.nnbathy/r.surf.nnbathy
[2] http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.surf.nnbathy
--
Maciej Sieczka
http://www.sieczka.org