Hi,
I recently downloaded Grass 6.4.0 RC5 from
http://grass.itc.it/grass64/binary/mswindows/cygwin/
I installed it on an old PC with win98se and Cygwin 1.5.25.
The installed Grass seems to suffer from the same symptoms of bug 654
(http://trac.osgeo.org/grass/ticket/654)
even though this bug is
Thanks!
Balazs
2010. 03. 6, szombat keltezéssel 15.35-kor Hamish ezt írta:
Szabó Balázs wrote:
How it is possible install add-ons on ubuntu karmic koala?
I downloaded Hydrofoss from add-ons svn repository, and
according to the
addons wiki page typed the #make
Vas Zor wrote:
I recently downloaded Grass 6.4.0 RC5 from
http://grass.itc.it/grass64/binary/mswindows/cygwin/
I installed it on an old PC with win98se and Cygwin
1.5.25.
The installed Grass seems to suffer from the same symptoms
of bug 654 (http://trac.osgeo.org/grass/ticket/654)
even
GRASS is connected to a MySQL data base
I want to select polygons which are not 0
so do I do:
d.vect SiteGrid3 where SquareNumber0
or
v.db.select map=SiteGrid3 column=square_no where=0
I have a second non spatial table described below(right)
grass SiteGrid3 (one)Pottery table
I am trying to compile the r.univar.zonal addon on a Fedora11 64 bit machine
and using GRASS 6.5 (GRASS 6.5.svn (2010) Revision: 38990, updated last
week).
I used:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal
cd r.univar2.zonal/
make
I have a 3D vector [test_3D] created using v.drape, confirmed as 3D
with v.info. I used v.split to split the polyline at the vertices:
v.split input=test_3D output=test_3D_split vertices=2
The resulting vector [test_3D_split] is a 2D vector (i.e. it lost the
z geometry data according to
On Sun, Mar 7, 2010 at 7:13 PM, Dwight Needels need...@translucida.com wrote:
I have a 3D vector [test_3D] created using v.drape, confirmed as 3D with
v.info. I used v.split to split the polyline at the vertices:
v.split input=test_3D output=test_3D_split vertices=2
The resulting vector
On Mar 7, 2010, at 2:10 PM, Markus Neteler wrote:
On Sun, Mar 7, 2010 at 7:13 PM, Dwight Needels need...@translucida.com
wrote:
I have a 3D vector [test_3D] created using v.drape, confirmed as 3D
with
v.info. I used v.split to split the polyline at the vertices:
v.split input=test_3D
Hi,
2010/3/7 Markus Neteler nete...@osgeo.org:
cd v.split/
grep open * | grep new
main.c: Vect_open_new(Out, out_opt-answer, 0);
Is this intended behavior?
Certainly not ideal. I don't know if changing to
Vect_open_new(Out, out_opt-answer, WITH_Z);
would be sufficient (of course
On Sun, Mar 7, 2010 at 9:10 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2010/3/7 Markus Neteler nete...@osgeo.org:
cd v.split/
grep open * | grep new
main.c: Vect_open_new(Out, out_opt-answer, 0);
Is this intended behavior?
Certainly not ideal. I don't know if changing to
I have been importing multiple GPS tracks (of hiking trails) into
GRASS for averaging, then using v.out.gpsbabel to export a .gpx
track for use on my GPS. I used v.drape to pull elevations from a DEM
into the vector, and had hoped that using v.out.gpsbabel to export the
resulting 3D vector
Glynn,
thank you so much for sharing :-)
I understand that this way of using grass isn't recommended for (let
us say) beginners. Nevertheless, my aim was/is to put most of this
thread in a wiki-page because I consider it as very practical.
Before doing so I want to test more to look for gaps and
Nikos wrote:
So, when working on a project, it is best practice to stick
with grass-sessions?
There will be a number of opinions on this, and there are probably a number
of valid answers depending on the use-case and expertise level of the user.
Mine is that it is useful to use init.sh
Nikos wrote:
So, when working on a project, it is best practice to stick
with grass-sessions?
Hamish wrote:
There will be a number of opinions on this, and there are probably a number
of valid answers depending on the use-case and expertise level of the user.
( ...I guess there is no thing
Nikos Alexandris wrote:
The thing that troubles me most currently is: using normal grass
sessions you get entries recorded in
/grassdb/location/mapset/.bash_history while working with pure bash
shell entries go in ~/.bash_history.
- Merging existing grass-bash_history(-ies) with
Νίκος:
Is there a way to lock-out all
other versions of grass-modules from being detectable when I am already
inside a grass70 session?
Glynn:
The grassXY scripts prepend the GRASS directories to PATH,
LD_LIBRARY_PATH, etc. They won't remove any entries which are already
there.
I only
Nikos Alexandris wrote:
The thing that troubles me most currently is: using normal grass
sessions you get entries recorded in
/grassdb/location/mapset/.bash_history while working with pure bash
shell entries go in ~/.bash_history.
- Merging existing grass-bash_history(-ies) with
Apologies for a second post with the code. Just to make it easier to
read/ understand what I've changed.
Νίκος Αλεξανδρής wrote:
Is there a way to lock-out all other versions of grass-modules from
being detectable when I am already inside a grass70 session?
Glynn Clements wrote:
The
On Sun, Feb 28, 2010 at 02:09, Rich Shepard rshep...@appl-ecosys.com wrote:
On Sat, 27 Feb 2010, Rich Shepard wrote:
242856.60 431305.07 242551.88 432149.70
Oops! I forgot the 'id' at the beginning of the line.
So, after adding that I get a new warning:
WARNING: Wrong input format: id
19 matches
Mail list logo
