Hi,
I am trying to invert a DEM (i.e., make peaks basins and vice versa) but
there does not seem to be a module for this. I am assuming this can be done
through ' r.mapcalc ' which I have very limited experience.
I also want to get ' r.prominence ' from the Add-ons site but the
text file is not
Multiply the DEM by -1
In r.mapcalc do:
dem_inv = dem * -1
On Sat, Nov 21, 2009 at 12:01 PM, Bulent Arikan bulent.ari...@gmail.com wrote:
Hi,
I am trying to invert a DEM (i.e., make peaks basins and vice versa) but
there does not seem to be a module for this. I am assuming this can be done
Kind of a odd solution, but would it be possible to use the outputs of
r.param.scale to get the classed areas (i.e., peaks, pits, passes,
valleys) and then recode them as their opposite?
Alternatively, using r.mapcalc, can you multiply all the values by -1?
Mark
On Sat, Nov 21, 2009 at 9:01 AM,
On Sat, 21 Nov 2009, Richard Chirgwin wrote:
I'm trying to import E00 files generated by the DCW for West Russia, but
in the import the region settings are getting scrambled.
Richard,
I noticed with both v.in.ogr and v.in.e00 the regional coordinates would
be changed from what I originally
Daniel Victoria wrote:
Multiply the DEM by -1
In r.mapcalc do:
dem_inv = dem * -1
Or just negate it:
dem_inv = -dem
This is more efficient, although I doubt that the difference would be
noticeable in practice; I would expect reading and writing the data to
dwarf the computation.
Hi,
2009/11/21 Rich Shepard rshep...@appl-ecosys.com:
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon d.mon x0
using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x0] started
Set up region based on vector map.
g.region vect=lentic
GRASS 6.4.0svn
On Sat, 21 Nov 2009, Martin Landa wrote:
Set up region based on vector map.
g.region vect=lentic
Martin,
Well, that certainly explains things. The three themes have the same boundary
of
a very small square ... less than 100th of a second of latitude and
longitude. I've no idea how I did
After:
# v.patch -e input=x...@cos90,x...@cos90,x...@cos90,x...@cos90,x...@cos90
output=cos90_patch
# v.clean input=cos90_pa...@cos90 output=cos90_clean
type=point,line,boundary,centroid,area tool=break,snap,rmdupl,bpol
thresh=0.01
# v.dissolve input=cos90_cl...@cos90 output=cos90_diss
Hi,
2009/11/21 Luís Ferreira lferreira7...@gmail.com:
An similar error is documented.
http://trac.osgeo.org/grass/ticket/548
Any idea?
right, the bug still waits to be be fixed. PostgreSQL backend should work.
Martin
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
Starting grass64 from /usr4/grassbase/Oregon I request a listing of the
region's boundaries and see this:
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon g.region -l
north-west corner: long: 125:18:06.67543W lat: 41:38:42.416382N
north-east corner: long: 125:18:06.327366W lat: 41:38:42.431669N
Yes, connecting to postgresql solved the problem.
Luís
On Sat, 2009-11-21 at 20:48 +0100, Martin Landa wrote:
Hi,
2009/11/21 Luís Ferreira lferreira7...@gmail.com:
An similar error is documented.
http://trac.osgeo.org/grass/ticket/548
Any idea?
right, the bug still waits to be be
Rich Shepard wrote:
Starting grass64 from /usr4/grassbase/Oregon I request a listing of the
region's boundaries and see this:
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon g.region -l
north-west corner: long: 125:18:06.67543W lat: 41:38:42.416382N
north-east corner: long:
Rich Shepard wrote:
Please explain to me why g.region -l shows region corners outside the
coordinate values shown by g.region -p. Makes no sense to me when they are
both run from the same location/mapset:
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon g.region -p
projection: 99
Markus,
From here:
http://www.maproom.psu.edu/cgi-bin/dcw/dcwarea.cgi?Asia
...thence:
http://www.maproom.psu.edu/cgi-bin/dcw/dcwcountry0.cgi
...selecting Drainage Network takes you to:
http://www.maproom.psu.edu/cgi-bin/dcw/dcwmanager.cgi
...and finally you can get the download link.
On Sat, 21 Nov 2009, Glynn Clements wrote:
Because g.region -p shows the cartographic coordinates in metres/feet in
the specified coordinate system (LCC, with the origin at approximately
41:38:42N, 125:18:06W), while g.region -l shows the coordinates converted
to lat/lon.
The reason is almost
Hi Bulent,
I had a chance to mess around with the inverted DEM idea tonight.
Here's what seemed to produce the best results for identifying peaks.
r.mapcalc 'inverted.DEM = -DEM'
Then I ran r.terraflow on the inverted DEM to get a filled, inverted DEM
r.terraflow elevation=inverted.DEM
Compare
http://www.public.asu.edu/~cmbarton/files/temp/
peaks_from_terraflow.jpg
with
http://www.public.asu.edu/~cmbarton/files/temp/peaks_from_rparamscale_minic.jpg
(new version of the r.param.scale minic output)
Michael
C. Michael Barton
Director, Center for Social
Rich Shepard wrote:
Because g.region -p shows the cartographic coordinates in metres/feet in
the specified coordinate system (LCC, with the origin at approximately
41:38:42N, 125:18:06W), while g.region -l shows the coordinates converted
to lat/lon.
The reason is almost certainly
Here are nviz versions of the 2 peaks maps for comparison:
http://www.public.asu.edu/~cmbarton/files/temp/peaks_from_terraflow_nviz.jpg
http://www.public.asu.edu/~cmbarton/files/temp/peaks_from_rparamscale_minic_nviz.jpg
It seems like the inverted DEM/hydrology method identifies major peak
19 matches
Mail list logo
