Fiends,
I'm a GRASS newbie trying to choose between GRASS6 and GRASS7 for a new project. I'm working in R and PostgreSQL, but have lots of Arc stuff to import.
I realize that GRASS7 did away with d.mon, but is there really no replacement other than the full GUI? If I enter
grass70 -text /path/to/GISDBASE/LOCATION/MAPSET
it starts up, but doesn't change the prompt to indicate it's actually running. However, it obviously is, and responds to commands such as
g.list vect
as usual. In response to
d.rast layer
it calculates %s and then ends with no output. I tried, for example,
d.cairo
to get a window to plot into, but no such command exists. So, in frustration I try
g.gui wxpython
and get the whole GUI (which I emphatically DO NOT want) just to get the map console. At that point, commands such as
d.rast layer
run without error but produce no output,and the GUI seems corrupted and doesn't work either.
That's a long post, but the critical question is is GRASS 7 going to be strictly GUI driven? I hoipe not.
Thnaks, Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David W. Roberts office 406-994-4548
Professor and Head FAX 406-994-3190
Department of Ecology email droberts@montana.edu
Montana State University
Bozeman, MT 59717-3460
Dave Roberts wrote:
Fiends,
I'm a GRASS newbie trying to choose between GRASS6 and GRASS7 for a
new project. I'm working in R and PostgreSQL, but have lots of Arc
stuff to import.
I realize that GRASS7 did away with d.mon, but is there really no
replacement other than the full GUI? If I enter
grass70 -text /path/to/GISDBASE/LOCATION/MAPSET
it starts up, but doesn't change the prompt to indicate it's actually
running. However, it obviously is, and responds to commands such as
g.list vect
as usual. In response to
d.rast layer
it calculates %s and then ends with no output. I tried, for example,
d.cairo
to get a window to plot into, but no such command exists. So, in
frustration I try
g.gui wxpython
and get the whole GUI (which I emphatically DO NOT want) just to get the
map console. At that point, commands such as
d.rast layer
run without error but produce no output,and the GUI seems corrupted and
doesn't work either.
That's a long post, but the critical question is is GRASS 7 going to be
strictly GUI driven? I hoipe not.
Thnaks, Dave
Let's start with what operating system are you on and what installation
method did you use?
You want to make sure it works? then I would go with a stable release
not an unreleased in progress version, so GRASS 6.4 (Not sure why it's
not final release yet)
If you get GRASS 6.4 behaving properly then you might want to try 7.
GRASS 6.4 is also more likely to play nice with R packages like spgrass,
etc.
Enjoy,
Alex
Dave wrote:
I'm a GRASS newbie trying to choose between
GRASS6 and GRASS7 for a new project.
unless you are a programmer who is willing to help with development, as a
new user go with GRASS 6.4. If for no other reason than it's well
documented and it's a less hard than trying to learn a moving target..
for any "real" work always use a stable version. (that goes for anything)
I'm working in R and PostgreSQL, but have lots of Arc stuff to import.
not a problem. I'd love to see more PosgGIS+GRASS documentation, for now
there is this:
http://grass.osgeo.org/wiki/PostGIS
http://grass.osgeo.org/wiki/R_statistics
http://www.surfaces.co.il/?p=645
and Martin's bulk data import tool (wxGUI file menu)
I realize that GRASS7 did away with d.mon,
but is there really no replacement other than the full GUI?
there is. look for wximgview and ximgview in the visualization/
directory of the grass7 source code.
:: http://thread.gmane.org/gmane.comp.gis.grass.devel/38217/focus=38253
have a look for a left over map.ppm file wherever you ran your seemingly
do-nothing d.rast from.
Hamish
Alex wrote:
GRASS 6.4 (Not sure why it's not final release yet)
a couple of outstanding issues off the top of my head,
- python scripts are not happy on WinGrass (apparently ok in 6.5, so selective backporting of code should fix this)
- r.terraflow fails on WinGrass. 64bit improvements are rolling along on
the -dev list, but help is needed to get the 32bit Windows version of it
going in the mean time: https://trac.osgeo.org/grass/report/13
- probably the most important one: potentially replacing swig with ctypes
for python bindings. we don't want to get stuck supporting something which
we know is problematic for the life of 6.x. Improvements are rolling along
on the -dev list. An option is to ship 6.4 with swig disabled and enable
ctypes for 6.4.1 or 6.4.2 after it gets sorted out in trunk.
Hamish