Hi all.
As it has been discussed earlier, having location generated (and destroyed) on the fly would help a lot the casual qgis grass user to approach grass. The idea is to run an analysis by loading (r.external, v.external, v.in.ogr) data, generating a location from it, run, save the results as tif or shp, and destroy the location at the end, all without users noticing it (but explaining for future reuse).
The good news is that here at the hackfest we got a voulnteer willing to help with the coding (preferably in Python). Welcome Peter Loewe!
Anybody willing to help him with the first steps?
All the best.
--
http://www.faunalia.it/pc
On Sun, Nov 14, 2010 at 9:54 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Hi all.
As it has been discussed earlier, having location generated (and destroyed)
on the fly would help a lot the casual qgis grass user to approach grass.
The idea is to run an analysis by loading (r.external, v.external, v.in.ogr)
data, generating a location from it, run, save the results as tif or shp,
and destroy the location at the end, all without users noticing it (but
explaining for future reuse).
The good news is that here at the hackfest we got a voulnteer willing to
help with the coding (preferably in Python). Welcome Peter Loewe!
Great, Peter!
Anybody willing to help him with the first steps?
Sure - note that all ingredients are already there including the
"demolocation" which
comes with any GRASS binary package. Maybe that's easier discussed
over chat?
Markus
Markus Neteler wrote:
On Sun, Nov 14, 2010 at 9:54 AM, Paolo Cavallini <cavallini@faunalia.it>
wrote:Hi all.
As it has been discussed earlier, having location generated (and
destroyed)
on the fly would help a lot the casual qgis grass user to approach grass.
The idea is to run an analysis by loading (r.external, v.external,
v.in.ogr)
data, generating a location from it, run, save the results as tif or shp,
and destroy the location at the end, all without users noticing it (but
explaining for future reuse).
The good news is that here at the hackfest we got a voulnteer willing to
help with the coding (preferably in Python). Welcome Peter Loewe!Great, Peter!
Anybody willing to help him with the first steps?
Sure - note that all ingredients are already there including the
"demolocation" which
comes with any GRASS binary package.
The GRASS R package was for GRASS5, and does not work with GRASS 6. A better
mechanism is provided in the spgrass package as initGRASS(). The code of the
R function sets the environment variables, etc., for a location generated on
the fly (with an .GRASSRC file) in the running R temporary directory. When R
exits, the location goes away.
Roger
Markus Neteler wrote:
Maybe that's easier discussed over chat?
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-----
Roger Bivand
Economic Geography Section
Department of Economics
Norwegian School of Economics and Business Administration
Helleveien 30
N-5045 Bergen, Norway
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/on-the-fly-grass-location-tp5737110p5737837.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
On Sun, Nov 14, 2010 at 10:24 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Nov 14, 2010 at 9:54 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Hi all.
As it has been discussed earlier, having location generated (and destroyed)
on the fly would help a lot the casual qgis grass user to approach grass.
The idea is to run an analysis by loading (r.external, v.external, v.in.ogr)
data, generating a location from it, run, save the results as tif or shp,
and destroy the location at the end, all without users noticing it (but
explaining for future reuse).
The good news is that here at the hackfest we got a voulnteer willing to
help with the coding (preferably in Python). Welcome Peter Loewe!Great, Peter!
Anybody willing to help him with the first steps?
Sure - note that all ingredients are already there including the
"demolocation" which comes with any GRASS binary package.
Maybe that's easier discussed over chat?
Forgot to mention this Wiki page
http://grass.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
Markus
Several changes were made in r.sim.water recently but it has still some troubles on non-linux machines.
GRASS64: it runs on linux, but gives Segmentation fault on Mac and Windows
Glynn has fixed the segmentation fault problem in GRASS7, I believe it is r42402(?)
http://trac.osgeo.org/grass/changeset/42402
but the fix was not backported to GRASS6 develbranch or GRASS64, so those two do not run on Mac or Windows
GRASS65 selfcompiled on Mac and linux - runs for me but I don't see Glynn's fix in the svn
GRASS7 selfcompiled on Mac and linux - here most changes were made,
but all cannot be backported because as names of some options were changed recently,
it now runs only with some of the them, but with the constant input values it says:
ERROR: Invalid descriptor: 0
below are some test runs if anybody wants to try it out. It would be great if the fix in GRASS7 made it
into the GRASS6.4.1 release and if the GRASS7 problem was fixed (I can look into the second one),
thank you,
Helena
#test for GRASS65
#location nc_spm_08
#mapset user1
g.region rural_1m res=2
r.mapcalc man0_1=0.1
r.mapcalc infil0=0.
r.mapcalc rain42mmhr=42.
v.surf.rst -dz input=elev_lid792_bepts layer=0 elev=elev_lid792_2m slope=dx_2m aspect=dy_2m ten=15 smooth=1.5 segmax=25 npmin=100
# run with defaults
r.sim.water -t elev=elev_lid792_2m dx=dx_2m dy=dy_2m depth=A1wdp_2mc disch=A1disch_2mc nwalk=200000
# run with input raster maps
r.sim.water -t elevin=elev_lid792_2m dxin=dx_2m dyin=dy_2m rain=rain42mmhr infil=infil0 manin=man0_1 depth=A1wdp_2mtest disch=A1disch_2mtest. nwalk=200000 niter=25 outit=5 hmax=0.2 halpha=8.0 hbeta=1.0
# run with input values
r.sim.water -t elevin=elev_lid792_2m dxin=dx_2m dyin=dy_2m rain_val=42 infil_val=0. manin_val=0.1 depth=A1wdp_2mtest disch=A1disch_2mtest nwalk=200000 niter=25 outit=5 hmax=0.2 halpha=8.0 hbeta=1.0
to check using animations you can use outit=1 and
xganim view1="A1disch_2mtest2*"
GRASS7
r.mapcalc expression="man0_1=0.1"
r.mapcalc expression="infil0=0."
r.mapcalc expression="rain42mmhr=42."
r.sim.water -t elev=elev_lid792_2m dx=dx_2m dy=dy_2m rain=rain42mmhr infil=infil0 man=man0_1 depth=A1wdp_2mtest2 disch=A1disch_2mtest2 nwalk=200000 niter=25 outit=5 hmax=0.2 halpha=8.0 hbeta=1.0
runs OK
the command below gives
ERROR: Invalid descriptor: 0
r.sim.water -t elev=elev_lid792_2m dx=dx_2m dy=dy_2m rain_val=42 infil_val=0. man_val=0.1 depth=A1wdp_2mtest disch=A1disch_2mtest nwalk=200000 niter=25 outit=5 hmax=0.2 halpha=8.0 hbeta=1.0
same when the module is run with defaults
r.sim.water -t elev=elev_lid792_2m dx=dx_2m dy=dy_2m depth=A1wdp_2mc disch=A1disch_2mc nwalk=200000
Note on GUI - is there any way to extend the list of files in the browser of the GUI - I can see only 9 files at once on MacHelena
On Fri, Nov 26, 2010 at 6:12 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Several changes were made in r.sim.water recently but it has still some troubles on non-linux machines.
GRASS64: it runs on linux, but gives Segmentation fault on Mac and Windows
Glynn has fixed the segmentation fault problem in GRASS7, I believe it is r42402(?)
http://trac.osgeo.org/grass/changeset/42402
but the fix was not backported to GRASS6 develbranch or GRASS64, so those two do not run on Mac or Windows
I have backported r42402 to GRASS 6.5.
Please try - if it helps, we can backport to 6.4, too.
Is there another changeset to be backported?
Markus
Helena Mitasova wrote:
GRASS64: it runs on linux, but gives Segmentation fault on Mac and Windows
Glynn has fixed the segmentation fault problem in GRASS7, I believe it is r42402(?)
r42402 shouldn't have any effect upon the resulting binaries; it just
cleaned up the source code. The only other changes I've made to that
code were related to library changes.
--
Glynn Clements <glynn@gclements.plus.com>
On Nov 26, 2010, at 9:05 AM, Markus Neteler wrote:
On Fri, Nov 26, 2010 at 6:12 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Several changes were made in r.sim.water recently but it has still some troubles on non-linux machines.
GRASS64: it runs on linux, but gives Segmentation fault on Mac and Windows
Glynn has fixed the segmentation fault problem in GRASS7, I believe it is r42402(?)
http://trac.osgeo.org/grass/changeset/42402
but the fix was not backported to GRASS6 develbranch or GRASS64, so those two do not run on Mac or WindowsI have backported r42402 to GRASS 6.5.
Please try - if it helps, we can backport to 6.4, too.
I just updated and recompiled GRASS65 and it runs well at least on Mac.
So yes please backport to 6.4 too.
what is going into GRASS6.4.1? everything in GRASS65 or only a selected subset of fixes?
I am asking because the GUI in GRASS65 has many improvements that make
running GRASS through GUI much more efficient.
Is there another changeset to be backported?
r43599 for v.surf.rst is in GRASS65 so it should go into GRASS64 (but I have never tested this one).
thanks a lot and it would be great to see GRASS6.4.1 soon so that we can install and test it before
everybody leaves for holidays
Helena
Markus
Quick question about GUI on Mac - is there any way to expand the element list (list of the available raster or vector maps)
for Add raster or Add vector panels, or at least set its size in the GUI settings? On Mac I can see only 9 raster map layers at once and it takes some effort to "catch" the map I am looking for when scrolling through 100+ maps (g.list rast with d.rast works
actually better in such case).
thanks,
Helena
Hi,
2010/12/2 Helena Mitasova <hmitaso@unity.ncsu.edu>:
Quick question about GUI on Mac - is there any way to expand the element list (list of the available raster or vector maps)
for Add raster or Add vector panels, or at least set its size in the GUI settings? On Mac I can see only 9 raster map layers at once and it takes some effort to "catch" the map I am looking for when scrolling through 100+ maps (g.list rast with d.rast works
actually better in such case).
auto-completion of elements would help also, is it right?
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Thu, Dec 2, 2010 at 3:15 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
On Nov 26, 2010, at 9:05 AM, Markus Neteler wrote:
On Fri, Nov 26, 2010 at 6:12 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Several changes were made in r.sim.water recently but it has still some troubles on non-linux machines.
GRASS64: it runs on linux, but gives Segmentation fault on Mac and Windows
Glynn has fixed the segmentation fault problem in GRASS7, I believe it is r42402(?)
http://trac.osgeo.org/grass/changeset/42402
but the fix was not backported to GRASS6 develbranch or GRASS64, so those two do not run on Mac or WindowsI have backported r42402 to GRASS 6.5.
Please try - if it helps, we can backport to 6.4, too.I just updated and recompiled GRASS65 and it runs well at least on Mac.
So yes please backport to 6.4 too.
I have done so in r44518.
what is going into GRASS6.4.1? everything in GRASS65 or only a selected subset of fixes?
Only selected things from 6.5
I am asking because the GUI in GRASS65 has many improvements that make
running GRASS through GUI much more efficient.
I dunno but I understood that the *GUI* is in complete sync (the other
files not).
Is there another changeset to be backported?
r43599 for v.surf.rst is in GRASS65 so it should go into GRASS64 (but I have never tested this one).
The entire z support was not backported. Done so now.
Still there is this warning
main.c:706: warning: passing argument 41 of ‘IL_init_params_2d’ from
incompatible pointer type
/home/neteler/grass64_release/dist.x86_64-unknown-linux-gnu/include/grass/interpf.h:82:
note: expected ‘struct FILE *’ but argument is of type ‘char *’
thanks a lot and it would be great to see GRASS6.4.1 soon so that we can install and test it before
everybody leaves for holidays
I agree.
cheers
Markus
Hi,
2010/12/2 Markus Neteler <neteler@osgeo.org>:
I am asking because the GUI in GRASS65 has many improvements that make
running GRASS through GUI much more efficient.I dunno but I understood that the *GUI* is in complete sync (the other
files not).
right.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Thu, Dec 2, 2010 at 2:05 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Thu, Dec 2, 2010 at 3:15 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
r43599 for v.surf.rst is in GRASS65 so it should go into GRASS64 (but I have never tested this one).
The entire z support was not backported. Done so now.
Still there is this warning
main.c:706: warning: passing argument 41 of ‘IL_init_params_2d’ from
incompatible pointer type
/home/neteler/grass64_release/dist.x86_64-unknown-linux-gnu/include/grass/interpf.h:82:
note: expected ‘struct FILE *’ but argument is of type ‘char *’
A known issue, see ticket #1173.
Markus M
just for the record - r.sim.water now runs on MSWindows as well
tested with the latest
http://josef.fsv.cvut.cz/wingrass/grass65/WinGRASS-6.5.SVN-r44504-1-Setup.exe
thanks a lot,
Helena
On Dec 2, 2010, at 8:21 AM, Markus Metz wrote:
On Thu, Dec 2, 2010 at 2:05 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Thu, Dec 2, 2010 at 3:15 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
r43599 for v.surf.rst is in GRASS65 so it should go into GRASS64 (but I have never tested this one).
The entire z support was not backported. Done so now.
Still there is this warning
main.c:706: warning: passing argument 41 of ‘IL_init_params_2d’ from
incompatible pointer type
/home/neteler/grass64_release/dist.x86_64-unknown-linux-gnu/include/grass/interpf.h:82:
note: expected ‘struct FILE *’ but argument is of type ‘char *’A known issue, see ticket #1173.
Markus M