I was compiling recent svn trunk (r30180) and vdigit failed to build
(link). As trac issue #38 is closed, I assume wx related stuff
detection now works and this must be my fault. What I did wrong?
OS: 32bit Gentoo ~x86
GRASS: svn-trunk r30180
GCC: 4.2.2 (Gentoo 4.2.2 p1.0)
wxWidgets: 2.8.7
c++ -c
Tried to import your file on a mac into spearfish location.
Have the same problem you report. But r.stats shows that the data are there.
So I tried to do a d.what.rast on the landuse map that shippes with
spearfish, where I do see data and know I should get a number. but
same here. I get novalues e
Michael Barton wrote:
I've attached a simple text file that I read into GRASS with
r.in.ascii.
r.in.ascii -f input=/Users/cmbarton/Desktop/
landuse_stats_all_models_orig2.txt output=landuse2 --overwrite
(I've tried it with -d, -ifd, and no flags)
It imports fine with no errors. It disp
Michael Barton wrote:
> I've attached a simple text file that I read into GRASS with r.in.ascii.
>
> r.in.ascii -f input=/Users/cmbarton/Desktop/
> landuse_stats_all_models_orig2.txt output=landuse2 --overwrite
>
> (I've tried it with -d, -ifd, and no flags)
>
> It imports fine with no error
#38: configure.in: wxwidgets and python checks
--+-
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: task | Status: closed
Priority: minor| Milestone: 6.4.0
#44: ./configure: cosmetics
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: closed
Priority: trivial | Milestone: 6.4.0
C
Martin Landa wrote:
> > Although, personally I wouldn't bother with the --includes and --libs
> > checks. Those flags are already included in the --cflags and --ldflags
> > checks. Having separate variables could lead to confusion; e.g. using
> > $(PYTHON_INCLUDES) instead of $(PYTHON_CFLAGS)
Roger Bivand wrote:
> > What r.series and r.resamp.stats need is:
> >
> > Initialise R
> > For each cell:
> > push a vector of doubles into R
> > call the R function on the vector
> > pull the result (a single double) from R
> > Shut down R
>
> Cer
I've attached a simple text file that I read into GRASS with r.in.ascii.r.in.ascii -f input=/Users/cmbarton/Desktop/landuse_stats_all_models_orig2.txt output=landuse2 --overwrite(I've tried it with -d, -ifd, and no flags)It imports fine with no errors. It displays fine. r.info shows that it contai
Hi,
2008/2/15, Glynn Clements <[EMAIL PROTECTED]>:
> Martin Landa wrote:
>
> > > The last version of patch [1] uses --with-python=[path/python-config]
> > > approach. Since I am not autoconf guru I cannot comment Ivan's notes.
> > >
> > > [1] http://trac.osgeo.org/grass/attachment/ticket/38
Michael Barton wrote:
> I remember a year or so ago, a users made a very good suggestion that
> we not have menus more than 2 levels deep and that menu item names
> should be shorter. This was difficult to do, given GRASS's
> complexity. But having done it, I think it helped usability a lot.
On 15.02.2008 17:23, Michael Barton wrote:
In theory, a usability study would be very helpful. But (big caveat), I
worry about results from someone who doesn't understand GIS. This
concern comes from several years of fielding well-meaning suggestions
(often the same ones repeated) from newbys t
On Feb 15, 2008, at 2:53 AM, [EMAIL PROTECTED] wrote:
Date: Fri, 15 Feb 2008 11:53:17 +0200
From: Wolf Bergenheim <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] GRASS in a usability review
To: Tim Michelsen <[EMAIL PROTECTED]>
Cc: GRASS developers list
Message-ID: <[EMAIL PROTECTED]>
Content-Typ
On Feb 15, 2008, at 2:53 AM, [EMAIL PROTECTED] wrote:
Everything seems to work, so I've enabled g.gui now in the Makefile as
the preferred way to start a GUI. It is hoped that the "wxgui" script
can be moved into $GISBASE/etc/wxpython/ from $GISBASE/scripts/ now.
Hopefully there are no issues
On Thu, 14 Feb 2008, Glynn Clements wrote:
Roger Bivand wrote:
What would be particularly useful is if it's possible for GRASS to use
R functions on small amounts of data. E.g. r.series and r.resamp.stats
both compute aggregates over relatively small amounts of data.
This is essentially wha
Hamish:
> > The g.mapsets module insists on putting the current one first, I
> > suppose it is possible to hack the $MAPSET/SEARCH_PATH file
> > manaually to change the order, but I don't know why someone would
> > want to.
Glynn:
> AFAICT, g.mapsets adds the current mapset to the head of the searc
Hamish wrote:
> > Yet again: an unqualified input map name does *not* refer to a map in
> > the current mapset. It refers to the first map with that name in the
> > search path. They aren't the same thing.
>
> I was not aware that it was possible for the current mapset NOT to be
> the first entr
On 13.02.2008 23:57, Tim Michelsen wrote:
Hello GRASS developers,
OpenUsabilty has opened a call for projects to participate the SoC like
usability review. The deadline is the 20.02.2008.
Since I think that GRASS could really benefit from such a opportunity I
took the freedom to create a wiki
Hamish wrote:
> > > It is trying to append _{$TMP} after [EMAIL PROTECTED] instead of just
> > > 'map'.
> > >
> > > Try this:
> > > http://trac.osgeo.org/grass/changeset/30118
> > > (really please try that, I haven't tested it)
> > >
> > > +++ /grass/trunk/scripts/v.db.addtable/v.db.addtable
19 matches
Mail list logo
