Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Thanks for the help, Markus N. and Markus M. – Grass compiles and builds 
successfully with proj 5.2.0.

Cheers,

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 13:16
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn

Hi Eric,

On Wed, May 22, 2019 at 6:01 PM Patton, Eric (NRCan/RNCan) 
mailto:eric.pat...@canada.ca>> wrote:
>
> Thanks for that info. So would a suitable strategy be to try re-synching  
> Grass from git,

yes, with "git pull"

then compiling and building with proj 6.1, and if that fails, try the proj 
5.9.3 release?

As I wrote earlier, GRASS should now build with proj 6, but coordinate 
operations can produce wrong results.

proj-5.2.0 is the latest proj 5 release, GRASS is working with proj-5.2.0

Markus M

> ~ Eric.
>
>
>
> From: Markus Metz 
> mailto:markus.metz.gisw...@gmail.com>>
> Sent: May 22, 2019 12:57
> To: Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>>
> Cc: grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>> wrote:
> >
> > Markus -
> >
> > Yes, I am using proj 6.0.0 – built with no errors.
>
>
>
> be aware that GRASS might compile with PROJ 6, but it is not working, too 
> much has changed from PROJ 5 and all those changes are not yet considered in 
> GRASS. Most importantly, coordinate transformations might produce wrong 
> results.
>
>
>
> Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+, 
> because of bug fixes and important new functionality.
>
> >
> > I believe I checked out master with ‘git clone 
> > https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be 
> > present in my source tree?
>
>
>
> It depends when you updated master the last time. If in doubt, git pull again.
>
>
>
> Markus M
>
>
>
> >
>
> >
> >
> > ~ Eric.
> >
> >
> >
> > From: Markus Metz 
> > mailto:markus.metz.gisw...@gmail.com>>
> > Sent: May 22, 2019 12:25
> > To: Markus Neteler mailto:nete...@osgeo.org>>
> > Cc: Patton, Eric (NRCan/RNCan) 
> > mailto:eric.pat...@canada.ca>>; 
> > grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>
> > Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
> >
> >
> >
> >
> >
> > On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
> > mailto:nete...@osgeo.org>> wrote:
> > >
> > > Hi Eric,
> > >
> > > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> > > mailto:eric.pat...@canada.ca>> wrote:
> > > >
> > > > Hi Markus,
> > > >
> > > > I noted your new installation instructions for the git repo and have 
> > > > used those.
> > > >
> > > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > > >
> > > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > > gcc  -

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Thanks for that info. So would a suitable strategy be to try re-synching  Grass 
from git, then compiling and building with proj 6.1, and if that fails, try the 
proj 5.9.3 release?

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 12:57
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn



On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) 
mailto:eric.pat...@canada.ca>> wrote:
>
> Markus -
>
> Yes, I am using proj 6.0.0 – built with no errors.

be aware that GRASS might compile with PROJ 6, but it is not working, too much 
has changed from PROJ 5 and all those changes are not yet considered in GRASS. 
Most importantly, coordinate transformations might produce wrong results.

Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+, 
because of bug fixes and important new functionality.
>
> I believe I checked out master with ‘git clone 
> https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be 
> present in my source tree?

It depends when you updated master the last time. If in doubt, git pull again.

Markus M

>
>
>
> ~ Eric.
>
>
>
> From: Markus Metz 
> mailto:markus.metz.gisw...@gmail.com>>
> Sent: May 22, 2019 12:25
> To: Markus Neteler mailto:nete...@osgeo.org>>
> Cc: Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>>; 
> grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
> mailto:nete...@osgeo.org>> wrote:
> >
> > Hi Eric,
> >
> > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> > mailto:eric.pat...@canada.ca>> wrote:
> > >
> > > Hi Markus,
> > >
> > > I noted your new installation instructions for the git repo and have used 
> > > those.
> > >
> > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > >
> > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > do_proj.c: In function ‘GPJ_init_transform’:
> > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > >   else {
> > >   ^~~~
> > > do_proj.c: At top level:
> > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL)
> > >  ^~
> > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL) {
> > >  ^~
> > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > > before ‘->’ token
> > >  info_trans->meters = 1.;
> > >^~
> > > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > > before ‘-

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Markus -

Yes, I am using proj 6.0.0 – built with no errors.

I believe I checked out master with ‘git clone 
https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be present 
in my source tree?

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 12:25
To: Markus Neteler 
Cc: Patton, Eric (NRCan/RNCan) ; 
grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn



On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> mailto:eric.pat...@canada.ca>> wrote:
> >
> > Hi Markus,
> >
> > I noted your new installation instructions for the git repo and have used 
> > those.
> >
> > The first error in error.log occurs in /usr/local/grass/lib/proj:
> >
> > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > do_proj.c: In function ‘GPJ_init_transform’:
> > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> >   else {
> >   ^~~~
> > do_proj.c: At top level:
> > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL)
> >  ^~
> > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL) {
> >  ^~
> > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > before ‘->’ token
> >  info_trans->meters = 1.;
> >^~
> > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > before ‘->’ token
> >  info_trans->zone = 0;
> >^~
> > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> >  sprintf(info_trans->proj, "pipeline");
> >^~
> > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> >  return 1;
> >  ^~
> > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> >  }
> >  ^
> > ../../include/Make/Compile.make:32: recipe for target 
> > 'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > make: *** Waiting for unfinished jobs
>
> ok, there seems to be a problem with the PROJ installation.

No, it's a problem with the #ifdef's in do_proj.c accounting for different 
versions of PROJ
>
> Which proj version do you use? Please post the names of the related
> packages here which you have installed (so that we see the precise
> version names).

This must be PROJ 6.

do_proj.c should be fixed in master 7c3e8de:
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f

Markus M

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Hi Markus,

I noted your new installation instructions for the git repo and have used 
those. 

The first error in error.log occurs in /usr/local/grass/lib/proj:
 
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
do_proj.c: In function ‘GPJ_init_transform’:
do_proj.c:136:6: error: expected ‘}’ before ‘else’
  else {
  ^~~~
do_proj.c: At top level:
do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
 if (info_trans->pj == NULL)
 ^~
do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
 if (info_trans->pj == NULL) {
 ^~
do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘->’ token
 info_trans->meters = 1.;
   ^~
do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘->’ token
 info_trans->zone = 0;
   ^~
do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
 sprintf(info_trans->proj, "pipeline");
   ^~
do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
 return 1;
 ^~
do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
 }
 ^
../../include/Make/Compile.make:32: recipe for target 
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
make: *** Waiting for unfinished jobs

Thanks,

~ Eric.




-Original Message-
From: Markus Neteler  
Sent: May 21, 2019 16:49
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn

Hi Eric,

On Tue, May 21, 2019 at 6:00 PM Patton, Eric (NRCan/RNCan) 
 wrote:
...
> I was running Grass 7.7svn (trunk) fine last week, and updated to v74509 
> today on Linux Mint 19.1.

We just moved to GitHub:

git clone https://github.com/OSGeo/grass.git

However, a question:

> No errors during configure, but make showed many errors of the type:
>
> Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/xmmintrin.h:120: Syntax error 
> at '{'

I guess that these error messages appear in the ctypes part which is
(unfortunately) "normal" and apparently not an issue.
...

> There’s far too many errors to list here, but the result of it is that 221 
> grass modules fail to build.

Which is the first one listed in
error.log
?

Can you then cd into that directory, run "make" therein and report the error?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Hi,

I was running Grass 7.7svn (trunk) fine last week, and updated to v74509 today 
on Linux Mint 19.1. No errors during configure, but make showed many errors of 
the type:

Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/xmmintrin.h:120: Syntax error at 
'{'
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/xmmintrin.h:887: Syntax error at 
'{'
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/xmmintrin.h:894: Syntax error at 
'{'
...
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/emmintrin.h:68: Syntax error at 
'{'
...
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:13330: Syntax 
error at '__v8si'
...
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:13414: Syntax 
error at '__m256i'
...
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:13632: Syntax 
error at '__m512i'
..
Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/sgxintrin.h:96: Syntax error at 
'__volatile__'

...and many other similar errors in other header files.

There's far too many errors to list here, but the result of it is that 221 
grass modules fail to build. Hopefully this class of error messages will be 
familiar to experts.

As I mentioned, I have all dependencies satisfied and no problems building 
grass last week (last time was around Wednesday, I think.)

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to modify PS1 variable

[Patton, Eric (NRCan/RNCan)]

Micha, I don't have a bashrc file in ~.grass7. And copying ~/.grass.bashrc to 
~/.grass7/bashrc and restarting Grass doesn't change anything (PS1 remains the 
same). It seems the grass77 startup is clobbering all other places where $PS1 
is set.

~ Eric.

From: Micha Silver 
Sent: February 28, 2019 11:49
To: Patton, Eric (NRCan/RNCan) ; 
grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Unable to modify PS1 variable


On 28/02/2019 16:10, Patton, Eric (NRCan/RNCan) wrote:
Hi, I am having trouble changing my PS1 bash prompt in Grass 7.7svn. I have PS1 
set to "\W >" in ~/.grass.bashrc, but instead my prompt consistently prints

"GRASS 7.7.svn ($LOCATION_NAME):\w > "  (with LOCATION_NAME and \W expanded to 
current Grass location and full directory path, respectively). The result is my 
prompt is eating almost the full width of my shell window.

Just wondering what other resource files need to be changed?

On my system (Debian, GRASS 7.6) it's ~/.grass7/bashrc



Thanks,

~ Eric.



___

grass-user mailing list

grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/grass-user

--

Micha Silver

Ben Gurion Univ.

Sde Boker, Remote Sensing Lab

cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to modify PS1 variable

[Patton, Eric (NRCan/RNCan)]

Thanks for that, Markus, that works.

~ Eric.

From: Markus Metz 
Sent: February 28, 2019 12:08
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Unable to modify PS1 variable



On Thu, Feb 28, 2019 at 3:21 PM Patton, Eric (NRCan/RNCan) 
mailto:eric.pat...@canada.ca>> wrote:
>
> Hi, I am having trouble changing my PS1 bash prompt in Grass 7.7svn. I have 
> PS1 set to “\W >” in ~/.grass.bashrc, but instead my prompt consistently 
> prints
>
> “GRASS 7.7.svn ($LOCATION_NAME):\w > “  (with LOCATION_NAME and \W expanded 
> to current Grass location and full directory path, respectively). The result 
> is my prompt is eating almost the full width of my shell window.
>
> Just wondering what other resource files need to be changed?

You could directly hack the GRASS startup script grass77, there in the fn 
bash_startup() the line that defines PS1, around L1772.

HTH,

Markus M

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to modify PS1 variable

[Patton, Eric (NRCan/RNCan)]

On Thu, Feb 28, 2019 at 3:20 PM Patton, Eric (NRCan/RNCan) 
 wrote:
>>
>> Hi, I am having trouble changing my PS1 bash prompt in Grass 7.7svn. I 
>>have
>> PS1 set to “\W >” in ~/.grass.bashrc, but instead my prompt 
>> consistently prints
>>
>> “GRASS 7.7.svn ($LOCATION_NAME):\w > “  (with LOCATION_NAME and \W 
>> expanded to current Grass location and full directory path, 
>> respectively). The result is my prompt is eating almost the full width of my 
>> shell window.
>
>Just to be sure: what is $SHELL set to? What is the output of:
>
>
>echo $SHELL
>
> and
>
>ls -la $(which $SHELL)

Markus, 

Here is the output:

echo $SHELL
/bin/bash

ls -al $(which $SHELL)
-rwxr-xr-x 1 root root 1037440 May 26  2017 /bin/bash

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Unable to modify PS1 variable

[Patton, Eric (NRCan/RNCan)]

Hi, I am having trouble changing my PS1 bash prompt in Grass 7.7svn. I have PS1 
set to "\W >" in ~/.grass.bashrc, but instead my prompt consistently prints

"GRASS 7.7.svn ($LOCATION_NAME):\w > "  (with LOCATION_NAME and \W expanded to 
current Grass location and full directory path, respectively). The result is my 
prompt is eating almost the full width of my shell window.

Just wondering what other resource files need to be changed?


Thanks,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Joining attributes of points to spatially-coincident line vertices

[Patton, Eric (NRCan/RNCan)]

>Not sure what your overall goal is here. (Won't the slopes along the coastline 
>all be about 0?). If there are >two adjacent points with different slopes from 
>the raster, which value would you want to attach to the line >segment between 
>those points?

I am trying to assign a general raster slope to a segment of coastline that is 
representative of the steepness of that roughly 100m2 raster pixel. Yes, 
technically the slope is 0 at the waterline, but what we are trying to assign 
to the vector shoreline is a slope value that is more representative of the 
backshore, to give an idea of how sensitive the coastline might be to sea-level 
inundation and erosion. I was able to assign the raster slope to the vector 
points using v.distance, but getting the slopes onto the coastline line vector 
with a spatial join seems to be very difficult if not impossible in Grass.
As for the problem of which of two points to assign to a vector line segment, I 
thought there might be a function to choose the median value of the two points, 
or some other statistic – ArcGIS provides a way to do this through their 
spatial join module.
>But you could approach the task in a different, more straightforward way:
>Run the module v.split on your original coastline line vector and split to 
>segments at whatever max distance >you choose, Then run v.rast.stats with that 
>split line as input and use your slope raster to derive slopes. The >result 
>will be an attribute table attached to the coastline vector with min,max,mean, 
>etc raster values for >each line segment.

Your method is interesting, I would like to try that on a sample section and 
see how the processing time compares to the v.distance method. Since I am 
working with the entire coastline of Canada, I don’t think I will have time to 
rerun the process with v.rast.stats. I might take several weeks just to 
complete the v.split portion.
Thanks for the ideas though,
~ Eric.

On 03/06/2018 06:02 PM, thepatton...@gmail.com 
wrote:



I have a high-resolution vector coastline, and I extracted the vertices of this 
coastline to points using 'v.to.points use=vertex'. I am trying to find the 
nearest raster slope value from another map to these points, and then upload 
this slope to the attribute table of the vector points coastline. To do this, I 
converted the raster slope map to points with r.to.vect, and successfully 
uploaded the nearest slope value from the now vector slope map to the vector 
points coastline with v.distance, using a dmax=200.



Ok, now to my problem: I want to get the vector coastline points back onto the 
original vector *lines* coastline, with all the point attributes as well. Since 
the vector coastline points were derived from the vertices of the coastline map 
in the first place, they are spatially  coincident, but I can't find a 
processing method that does this. Ideally, I suppose the coastline points map 
could act as breakpoints to the coastline polyline map, and the attributes 
would be transferred based on a buffer of something like one metre or less.



Any ideas on how I might do this?



Thanks,



--

Eric

___

grass-user mailing list

grass-user@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/grass-user



--

Micha Silver

Ben Gurion Univ.

Sde Boker, Remote Sensing Lab

cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Break lines in vector A at locations of points in vector B

[Patton, Eric (NRCan/RNCan)]

Hi,

I have two vector maps, vector A is a line vector representing coastline, and 
vector B is vector points which are the vertices of vector A. Is there a way to 
split vector A into line segments using vector B as breakpoints? 

v.edit tool=break kind of does this, but seems to want coordinates given one at 
a time. I have hundreds of thousands of points, and this doesn't seem an 
efficient way of doing it. 

Thanks,

~ Eric. 

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problem creating secant Lambert Conformal Conic projection

[Patton, Eric (NRCan/RNCan)]

Markus,

Responding to a months-old post (sorry!)

Upgrading to proj 4.9.2 and gdal 2.1.2 seemed to fix the problem.

Both secant parallels in my Lambert Conformal projection are now being reported:

> g.proj -we
PROJCS["Lambert_Conformal_Conic",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Lambert_Conformal_Conic"],
PARAMETER["standard_parallel_1",65],
PARAMETER["standard_parallel_2",75],
PARAMETER["latitude_of_origin",65],
PARAMETER["central_meridian",-60],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

Sorry for the noise!

--
Eric 


From: neteler.os...@gmail.com <neteler.os...@gmail.com> on behalf of Markus 
Neteler <nete...@osgeo.org>
Sent: Tuesday, May 17, 2016 5:33 PM
To: Patton, Eric (NRCan/RNCan)
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] problem creating secant Lambert Conformal Conic 
projection

On Tue, May 17, 2016 at 7:28 PM, Patton, Eric (NRCan/RNCan)
<eric.pat...@canada.ca> wrote:
> Hi Markus,
>
> Sorry for the delay in responding. I am using Grass 7.0.5svn, proj 4.8.0,
> gdal 1.10.1.
>
> I really don’t understand what could be the cause of this. I tried a fresh
> checkout and install, and encountered the same behavior. I'm using the proj
> and gdal packages provided by my package manager, so there's no custom
> installations installed in parallel.

proj-4.8.0 is from roughly 13-Mar-2012

I use proj 4.9.1, 04 March 2015

Perhaps some fixes in between?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problem creating secant Lambert Conformal Conic projection

[Patton, Eric (NRCan/RNCan)]

??Hi Markus,

Sorry for the delay in responding. I am using Grass 7.0.5svn, proj 4.8.0, gdal 
1.10.1.

I really don't understand what could be the cause of this. I tried a fresh 
checkout and install, and encountered the same behavior. I'm using the proj and 
gdal packages provided by my package manager, so there's no custom 
installations installed in parallel.

~ Eric.


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.param.scale Question

[Patton, Eric]

I've run r.param.scale multiple times to extract the various terrain
parameters from both 10m and 25m elevation maps. I set the region (and
resolution) to that of the input elevation map. All maps but the
tangential
(planar) curvature map are properly rendered. This one comes out a
solid
color. I don't see what I'm doing incorrectly on this one map.

   Suggestions appreciated.

Rich


It's possible there are outliers in your raster map that are skewing the
color table; what is the result of r.info -r? Check to see the range of
the raster makes sense.

--
Eric
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Documents Manager position available

[Patton, Eric]

Grass users:

 

I'm sorry to report I must step down as the Grass documents manager. I 

am being reassigned to a new position within my organization, and much 

of my work will be non-GIS related, unfortunately. I'm sorry I was not 

able to contribute more updates than I have. I would, however, like to 

keep my svn commit privileges, with the PSC's permission, to be able 

to commit occasional updates from time to time. I will still need to 

use GIS for some work, and if I come across any Grass documentation

errors, I would like to be able to commit fixes for these.

 

Thanks and regards,

 

--

Eric Patton

Technologist, Geo-Spatial Data Services

Natural Resources Canada

Geological Survey of Canada (Atlantic)

Bedford Institute of Oceanography

 

1 Challenger Drive (P.O. Box 106)

Dartmouth, Nova Scotia, B2Y 4A2

 

Telephone:  (902) 426-7732 

Facsimile: (902) 426-4104

Email: epat...@nrcan.gc.ca

 

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Error installing v.label.sa

[Patton, Eric]

Using today's checkout of trunk, I get the following error after running make 
distclean, configure, make:

Errors in:
/usr/local/grass_trunk/vector/v.label.sa

$ cd /vector/v.label.sa
(make clean)

v.label.sa make
test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu
gcc -I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include  -g -O2   
-I/usr/local/include  -DPACKAGE=\grassmods\   -I/usr/include/freetype2/ 
-I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/annealing.o -c annealing.c
gcc -I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include  -g -O2   
-I/usr/local/include  -DPACKAGE=\grassmods\   -I/usr/include/freetype2/ 
-I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/labels.o -c labels.c
labels.c: In function ‘labels_init’:
labels.c:62: warning: format ‘%d’ expects type ‘int’, but argument 3 has type 
‘long unsigned int’
labels.c:68: warning: format ‘%d’ expects type ‘int’, but argument 2 has type 
‘long unsigned int’
labels.c:86: warning: assignment makes pointer from integer without a cast
labels.c:123: warning: format ‘%d’ expects type ‘int’, but argument 4 has type 
‘long unsigned int’
gcc -I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include  -g -O2   
-I/usr/local/include  -DPACKAGE=\grassmods\   -I/usr/include/freetype2/ 
-I/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/main.o -c main.c
gcc -L/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/lib 
-Wl,--export-dynamic 
-Wl,-rpath-link,/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/lib   -o 
/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/v.label.sa 
OBJ.x86_64-unknown-linux-gnu/annealing.o OBJ.x86_64-unknown-linux-gnu/labels.o 
OBJ.x86_64-unknown-linux-gnu/main.o  -lgrass_display -lgrass_gis 
-lgrass_datetime -lz -lgrass_raster -lgrass_pngdriver -lgrass_driver 
-lgrass_gis -lgrass_datetime -lz -lfreetype-lgrass_gis -lgrass_datetime 
-lz -lpng  -lz  -lm  -lgrass_psdriver -lgrass_driver -lgrass_gis 
-lgrass_datetime -lz -lfreetype-lgrass_gis -lgrass_datetime -lz  
-lgrass_driver -lgrass_gis -lgrass_datetime -lz -lfreetype-lgrass_gis 
-lgrass_datetime -lz   -lgrass_raster -lgrass_pngdriver -lgrass_driver 
-lgrass_gis -lgrass_datetime -lz -lfreetype-lgrass_gis -lgrass_datetime 
-lz -lpng  -lz  -lm  -lgrass_psdriver -lgrass_driver -lgrass_gis 
-lgrass_datetime -lz -lfreetype-lgrass_gis -lgrass_datetime -lz  
-lgrass_driver -lgrass_gis -lgrass_datetime -lz -lfreetype-lgrass_gis 
-lgrass_datetime -lz  -lgrass_vect -lgrass_dbmibase -lgrass_gis 
-lgrass_datetime -lz  -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis 
-lgrass_datetime -lz  -lgrass_gis -lgrass_datetime -lz  -lgrass_dgl 
-lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree  -lgrass_gis 
-lgrass_datetime -lz -lgrass_linkm -lgrass_rtree  -lgrass_dig2 -lgrass_gis 
-lgrass_datetime -lz -lgrass_rtree  -lgrass_dgl -lgrass_rtree -lgrass_linkm 
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz  
-lgrass_gis -lgrass_datetime -lz  -lgrass_dbmibase -lgrass_gis 
-lgrass_datetime -lz   -L/usr/local/lib -lgdal  -lgrass_gis 
-lgrass_datetime -lz -lfreetype   -lm  -lz 
OBJ.x86_64-unknown-linux-gnu/labels.o: In function `labels_init':
/usr/local/grass_trunk/vector/v.label.sa/labels.c:86: undefined reference to 
`find_font_from_freetypecap'
/usr/local/grass_trunk/vector/v.label.sa/labels.c:98: undefined reference to 
`free_freetypecap'
collect2: ld returned 1 exit status
make: *** [/usr/local/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/v.label.sa] 
Error 1

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Off Topic: Importing GRASS tiffs to GMT

[Patton, Eric]

By a tiff, do you mean a georeferenced map? I've plotted aerial photos 
that I rectified in GRASS using the following to export the RGB bands:

r.mapcalc image.red=r#image; image.green=g#image; image.blue=b#image
r.out.bin -h input=image.red output=image.red.grd
r.out.bin -h input=image.green output=image.green.grd
r.out.bin -h input=image.blue output=image.blue.grd

Followed by:

grdimage image.red.grd image.green.grd image.blue.grd -J -R -B ...etc.

I've just put the same workflow onto the wiki.  I've also used r.his to 
make coloured shaded relief maps, and plotted them in GMT using the same 
method.  I don't think that it is the optimal method, but at least it 
preserved my colour rules.

Cheers

John

I had forgotten about r.cpt2grass; thanks for the note, Hamish.

I found a posting by Allen Cogbill on the GMT mailing list last night,
and with a lot of clunky tweaking, worked for me:

1. Convert the .tif file to a Sun Rasterfile (I use ImageMagick).
2. Use Unix tools to read the .tfw file that accompanies the .tif
file and calculate the real-world coordinate extrema.
3. Using g.region or imagemagick's identify, list the number of rows
and columns, and along with the image resolution, calculate the N-S-E-W extents.
4. Once real-world extents are known, use your psbasemap mapping scale to 
calculate 
image width and height on paper.
5. Pass this information to psimage -W.

As long as the region defined in psbasemap's -R flag is identical to the region 
of the generated tiff from GRASS, the image will plot correctly. 

John, I was trying to import colored, shaded-relief tiff images using 
r.out.tiff. 
For whatever reason, r.out.tiff always preserves my color table as opposed to 
r.out.gdal.
Your solution sounds a lot easier to use than mine; I'll have to try it out - 
thanks!

Regards,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Off Topic: Importing GRASS tiffs to GMT

[Patton, Eric]

I'll post here before checking on the GMT list; hopefully I can get some 
answers from a GRASS/GMT guru...

I've exported a tiff from GRASS using r.out.tiff -t, producing a worldfile in 
the process. I then converted the tiff to an 8-bit Sun raster image using 
Imagemagick's convert utility (GMT will only import imagery in this format). So 
far so good, the image looks fine. My question is how do plot the Sun raster so 
that it is correctly georeferenced on my GMT basemap? The GMT program psimage 
doesn't have a -R flag with which I may feed it geographical coordinates! And 
grd2image is only used for gridding xyz data, not for plotting georeferenced 
images. 

I already wrote a bash script to extract the upper left coordinates from the 
worldfile and then convert these positions into GMT-style -R flag like this:

Worldfile:
  10.000 
   0.000 
   0.000 
 -10.000 
  710175.000 
 5418295.000

Output from my script:

-54.160355/48.399269/-53.359791/48.860100

But can this information actually be used to imoprt the Sun raster? 

Sorry for the off-topic post. I know there are a few GMT users in the GRASS 
community, and maybe they have encountered this problem before.

Thanks,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] openGL library name

[Patton, Eric]

Not sure. But I work with NVidia and have the following  under
/usr/include/GL$ ls -l

-rw-r--r-- 1 root root 376506 2009-01-06 22:13 glext.h
-rw-r--r-- 1 root root  72949 2009-01-06 22:13 gl.h
-rw-r--r-- 1 root root  17163 2008-10-22 05:58 glu.h
-rw-r--r-- 1 root root   3315 2008-10-22 05:58 glu_mangle.h
-rw-r--r-- 1 root root  33751 2009-01-06 22:13 glxext.h
-rw-r--r-- 1 root root  14021 2009-01-06 22:13 glx.h

Do you have all of those installed as well?
Nikos

Yep, looks good:

cd /usr/include/GL
GL ls -l
total 692
-rw-r--r-- 1 root root   5028 2008-05-10 09:20 freeglut_ext.h
-rw-r--r-- 1 root root681 2008-05-10 09:20 freeglut.h
-rw-r--r-- 1 root root  23684 2008-05-10 09:20 freeglut_std.h
-rw-r--r-- 1 root root 388018 2008-10-22 00:51 glext.h
-rw-r--r-- 1 root root  90754 2008-10-22 00:51 gl.h
-rw-r--r-- 1 root root  83950 2008-10-22 00:51 gl_mangle.h
-rw-r--r-- 1 root root  17163 2008-10-22 00:58 glu.h
-rw-r--r-- 1 root root   3315 2008-10-22 00:58 glu_mangle.h
-rw-r--r-- 1 root root639 2008-05-10 09:20 glut.h
-rw-r--r-- 1 root root  33458 2008-10-22 00:51 glxext.h
-rw-r--r-- 1 root root  15234 2008-10-22 00:51 glx.h
-rw-r--r-- 1 root root   3412 2008-10-22 00:51 glx_mangle.h
drwxr-xr-x 2 root root   4096 2008-10-29 10:12 internal

All of your files plus some mangle headers to boot.

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-stats] Re: [GRASS-user] Testing i.pca ~ prcomp(), m.eigensystem ~ princomp()

[Patton, Eric]

 than 1. The reasoning is fairly weak, but goes like this: if a PC has
 eigenvalue  1, it explains more variance than any of the original
 variables, which all have variance 1.
 
 Maybe I should Cc: this to the wiki.
 --
 Edzer

Or even better include it in the docs if there is anything in your post 
that does a better job explaining the module. I'm completely unfamiliar with
these modules, but could you suggest some portions of your explanation that 
would be useful for inclusion in the documentation?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] openGL library name

[Patton, Eric]

It's entirely possible that the nVidia OpenGL package doesn't have a
corresponding development package. In which case, you probably need to
make the symlink manually, e.g.:

   ln -s libGL.so.1.2 /usr/lib/libGL.so

Essentially libGL.so must exist in one of the system library
directories (e.g. /usr/lib) and must point (directly or indirectly) at
the actual OpenGL library (which will normally have a version number
after the .so).

Thanks, Glynn! That was exactly what was wrong.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] openGL library name

[Patton, Eric]

I think I accidentally allowed my OS to install a proprietary NVIDIA driver and 
as a result, some of my openGL libraries appear to be missing.

At any rate, running configure for GRASS 6.5 crashes when it reaches the openGL 
section: 

snip
checking for location of OpenGL includes... /usr/include/GL
checking for GL/gl.h... yes
checking for GL/glu.h... yes
checking for location of OpenGL library... 
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
configure: error: *** Unable to locate OpenGL library.

What are the names of packages that contain the required libraries?

Thanks,

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] openGL library name

[Patton, Eric]

I also use the proprietary NVIDIA driver, no problem.
Please check config.log for the real error.

Markus

Here's the relevant output from config.log:

configure:11398: checking for glBegin in -lGL
configure:11415: gcc -o conftest -g -O2 -Wl,--export-dynamic  -L/usr/lib64 
conftest.c -lGL   -lSM -lICE -lX11  -lm   15
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
configure: failed program was:
#line 11404 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char glBegin();

int main() {
glBegin()
; return 0; }
configure:11434: checking for glBegin in -lGL
configure:11451: gcc -o conftest -g -O2 -Wl,--export-dynamic  -L/usr/lib64 
conftest.c -lGL   -lSM -lICE -lX11  -lm -lXext  15
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
configure: failed program was:
#line 11440 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char glBegin();

int main() {
glBegin()
; return 0; }
configure:11470: checking for glBegin in -lGL
configure:11487: gcc -o conftest -g -O2 -Wl,--export-dynamic  -L/usr/lib64 
conftest.c -lGL   -lSM -lICE -lX11  -lm -lpthread  15
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
configure: failed program was:
#line 11476 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char glBegin();

int main() {
glBegin()
; return 0; }
configure:11506: checking for glBegin in -lGL
configure:11523: gcc -o conftest -g -O2 -Wl,--export-dynamic  -L/usr/lib64 
conftest.c -lGL   -lSM -lICE -lX11  -lm -lpthread -lXext  15
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
configure: failed program was:
#line 11512 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char glBegin();

int main() {
glBegin()
; return 0; }


~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] openGL library name

[Patton, Eric]

 configure:11398: checking for glBegin in -lGL
 configure:11415: gcc -o conftest -g -O2     -Wl,--export-dynamic  
 -L/usr/lib64 conftest.c -lGL   -lSM -lICE -lX11  -lm   15

I guess

sudo ldconfig

will not help (?).

Martin

Hm , no that doesn't seem to make any difference. I get the same error as 
before.

~ Eric.


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] scripting mapcalc

[Patton, Eric]

In general, it's preferable to do as much as possible in each
r.mapcalc command. E.g. rather than:

   r.mapcalc $GIS_OPT_OUTPUT.r = r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + 
 (1.0 - .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND
   r.mapcalc $GIS_OPT_OUTPUT.g = g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + 
 (1.0 - .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND
   r.mapcalc $GIS_OPT_OUTPUT.b = b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + 
 (1.0 - .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND

use:

   r.mapcalc EOF
   $GIS_OPT_OUTPUT.r = r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - 
 .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND
   $GIS_OPT_OUTPUT.g = g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - 
 .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND
   $GIS_OPT_OUTPUT.b = b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - 
 .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND
   EOF

as the latter will read each input map only once.

This is really good to know, thanks! I've added this hint to r.mapcalc.html in 
trunk (r36207) and devbr6 (36208).

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: v.generalize for area boundaries?

[Patton, Eric]

for v.generalize the bare description.html file is already 250 lines long,
so presumably already contains most important info. (although no examples)

FWIW, I've cleaned up the existing v.generalize html page by rewriting parts 
where I thought the meaning could be explained better, as well as spelling 
corrections and other misc. formatting in trunk, devbr6, and relbr64 (r35984, 
r35985 and r35986).

I'm not familiar at all with the functionality of the module, so examples will 
take a bit longer to work up.

~ Eric. 

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Zoom tool behavior confined to single-click only

[Patton, Eric]

Using a fresh svn update in both develbranch6 and trunk today, I've noticed 
that the wxgui Map Display's zoom tool only allows single-clicking to zoom in 
and zoom out. Is not no longer possible to draw a zooming box with these tools?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Aspect direction in r.slope.aspect

[Patton, Eric]

 Good topic for discussion. I think that GRASS7 should stick with the  
 current conventions to retain backwards compatibility. 
 Dylan

But I thought the whole idea of GRASS7 was to introduce new functionality 
that is not necessarily intended to be backwards compatible with 6.x series?
The place to make the change, if anywhere, must certainly be in 7 as so much 
else is changing in the codebase as well.

For my 2 cents worth, it seems to make a lot more sense for a  
*geographic* information system for all output to follow the same  
spatial organizational standards. 

I agree. Measuring counter-clockwise from east is completely counterintuitive
from my point of view. Why make it more complex than it needs to be? 

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Aspect direction in r.slope.aspect

[Patton, Eric]

I agree. Measuring counter-clockwise from east is completely counterintuitive
from my point of view. Why make it more complex than it needs to be? 

Sorry, just catching up to the discussion; I hadn't read some points in the 
thread
further along; just because it seems more complex to me doesn't necessarily 
make it so ;)

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Any success converting grc files?

[Patton, Eric]

can you send me sample grc file?

Martin

See attached. Thanks.

~ Eric.


NTS_MapSheets.grc
Description: NTS_MapSheets.grc
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] testing

[Patton, Eric]

Just a test!

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Any success converting grc files?

[Patton, Eric]

Hi gang,

Has anyone tried converting tcl/tk grc workspace files to wxgui workspace 
format recently? I have a grc I've been using with gis.m for some time, and 
converting it in the wxgui seems to hang and never complete (5 minutes, no 
success) - or maybe I'm too impatient.

~ Eric. 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Re: v.in.ascii howto

[Patton, Eric]

Hamish:
IMO spaces should be encouraged, but not mandatory.

Eric:
  I'll put a note in the docs saying it isn't necessary to pad with
  spaces.

Hamish:
I would just say nothing at all about it. At most something along the lines
of excess whitespace will be ignored, but then we have to guarantee that.

I would think it would be better to spend the effort to highlight the -n
flag for standard mode without header (ex. 1b).

Done. I've highlighted the function of -z and -n in Ex.1b, and applied a number 
of other
cleanups, to 6.4 and 7.0 as r34274 and r34273, respectively.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Re: v.in.ascii howto

[Patton, Eric]

The page also warns Note the blank before entering vertex
coordinates.  Is this strictly necessary?  Thanks.

What version of Grass are you using? I can't this message in 
the html help in either 6.4 or 7.0svn. 

Regardless, I've updated the examples to show the full command-line
import call. I can import vectors in standard format with or without spaces
on each coordinate line; I'll put a note in the docs saying it isn't 
necessary to pad with spaces.

(Aside: does anyone know why spaces were placed on each coordinate line
in v.in.ascii example 1a? Cosmetics?)

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] GRASS 6.4 and Ubuntu Intrepid

[Patton, Eric]

I did more testing about this problem, and I discovered this:
- No, I haven't more then 1 version of GDAL or GRASS in my system
- 6.4.0 and 6.2.3 report those errors while building:
Errors in:
/usr/src/grass-6.2.3/raster/r.drain
/usr/src/grass-6.2.3/raster/r.fill.dir
/usr/src/grass-6.2.3/raster/r.terraflow

I'll repeat the test using an older GDAL, and let you know.

Thanks
Luca

I can confirm the same errors. I'm using a clean installation of
8.10, with all Grass dependencies installed through Synaptic. 
(gdal 1.5.2, Grass 6.4 and 7svn installed).

Output from error.log:

GRASS GIS compilation log
-
Started compilation: Thu Oct 30 09:48:55 ADT 2008
--
Errors in:
/usr/local/grass6_devel/gui/wxpython/vdigit
/usr/local/grass6_devel/raster/r.drain
/usr/local/grass6_devel/raster/r.fill.dir
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Thu Oct 30 09:56:17 ADT 2008

The error with v.digit is related to the fact that it is not picking 
up the self-installed wxwidgets package that I had to fetch. The default 
wxwidgets version the ships with Ubuntu 8.10 is only version 2.6.3.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] using grass on rasters without converting?

[Patton, Eric]

Is there any program available, or a project
in the works, for easy in-and-out conversion? or better yet, a method to use
grass commands on external formats like geotiff without conversion? 

Have a look at r.external:

http://grass.itc.it/grass64/manuals/html64_user/r.external.html

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Tips for setting up an new FOSS-GEO-linux-box

[Patton, Eric]

OS:
OK, I think I shouldn't ask about which OS since foss runs on everything
(right?). But are I am curious to know if there are any advantages using
Debian instead of Ubuntu for example?

Everyone has their own favorite; I've been using Ubuntu and Grass together
since 2004, with no difficulties on 32-bit and 64-bit machines.

Filesystems:
Which filesystem is better(=safer/faster) for data storage? Is there any
important advantage to choose XFS for example rather than ext3?

Not sure about the main differences/advantages of either; I've been using ext3
since forever, with no regrets.

Partitions:
Do you keep your geo-data in a separate partition? I suppose yes. Have
you split further your partition based on other criteria, always related
with working with geospatial data?

Pretty much the main 3-4 projects I'm working on are on /home, with anything I
haven't worked on in the last 2-weeks backed up and archived on an external 
2TB hardrive. (LaCie)

Do you keep all of your source code in a separate partition maybe?

Nope, just under good old /usr/local. I only compile from scratch those 
applications where
I need all the bleeding edge goodies and bug fixes, which, for me, is only 
Grass,
gdal, and lilypond. I try to use the distribution's packages for everything 
else; 
makes it a lot easier to maintain using the package manager than chasing around 
and recompiling source for a ton of apps. 

Organisation:
GRASS takes care to organise the data inside the GIS data-base and its
fantastic. But what about the raw data? How do you organise them?
Manually everything? Any tool to be more productive?

Once raw data is imported into Grass, I usually get it off my hard drive and 
backed 
up onto something external, in case my computer melts down; then I can always
rebuild from scratch. Of course the external drive could also melt down. I guess
a RAID would be even better, but costs more.

BackUp:
How often do you backup your data? Do you just copy or do you compress
as well? What is safer?

I've been using 'tar cjvf' for each project, but that is becoming unmanageable; 
I need 
to migrate to a versioning system as Dylan has done with rsync. At least for the
projects I work on all the time. The old stuff can probably stay on the backup 
drive
in tar.bz2 format.


Other:
Any other important issues when setting-up a new foss-geo-box?

I just installed Ubuntu Intrepid 8.10 yesterday, and found it much easier
installing packages via Synaptic rather than downloading the bleeding edge
source packages and compiling. The only source package I had to compile was 
Grass.


Thank you, Nikos

P.S. Maybe we can add a new wiki-page if something useful comes out of
this thread. Or maybe not... :-)

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] readline completion under bash

[Patton, Eric]

Alas, it seems grass-complete doesn't work:
GRASS 6.3.1svn (msunduzi_lo31):~/GIS/scripts/grass-complete  . bash/Init.sh
Unable to initialize bash completions: bash is too old or too new:
BASH_VERSION= 3.2.25(1)-release (needed = 2.05)

I had contacted the author of Grass completions a few years ago 
to see if he was interested in perhaps updating it to a newer 
version of Bash:

http://article.gmane.org/gmane.comp.gis.grass.user/13851/match=completion

He showed some interest at the time, but I never heard anything further on it.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-dev] Re: [GRASS-user] How choosing the colors of an importedmap

[Patton, Eric]

FYI, I just committed a new interactive color management module to the  
wxPython GUI code this weekend (in both develbranch_6 [GRASS 6.4] and  
trunk [GRASS 7]).

It allows you to set colors for rasters by entering cat values or  
percents and clicking a color chooser button. There is a preview  
window that allows you to fine tune your color table.

Cool, very nice! I gave it a try in 6.4, seems to work great! Thanks for this 
feature,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] 6.3 v.distance description faulty / ll degrees notmeters

[Patton, Eric]

I've installed grass 6.3, since in the descritption of v.distance 
says In lat-long locations v.distance gives distances (dist and
to_along) in meters not in degrees calculated as geodesic distances
on a sphere..

I can confirm 'dist' units are indeed given in decimal degrees in a 
Lat/Long location in 6.4.

Devs, what is the intended behavior of the module? If this behavior 
is a bug, would it be a simple fix? Otherwise, I'll modify the
docs to mention reported units in degrees.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] 6.3 v.distance description faulty / ll degrees notmeters

[Patton, Eric]

 I can confirm 'dist' units are indeed given in decimal degrees in a
 Lat/Long location in 6.4.

do you mean 6.3?

No, I meant 6.4, but checking 6.3.1.svn, 'dist' units are decimal
degrees as well.

From r29568 [1] is distance (in LL locations) given in meters. Manual
pages in 6.3 should be fixed.

Sorry, I'm a little confused; from the changeset, it appears that v.distance
was being corrected to able to report in meters, as lat and lon are not 
equally scaled. So it seems that a bug in v.distance still exists, then? 
Shouldn't r29568 have fixed this? 

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Multiple errors after lengthy absence from Grass 7

[Patton, Eric]

As Martin says, GRASS 7 development has now started. The first phase
of development is to eliminate deprecated functionality. This will
break stuff. Eventually we should get around to replacing most of the
stuff which breaks with more usable alternatives. In the meantime, use
6.4 if you just want a working version.

Great, thanks for the update. I'll stick to using 6.4.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] XTF reader neede - triton format for sonar

[Patton, Eric]

Hamish:
But sounding out a plan of action doesn't cost much, so...

I had considered a few alternatives:

- create a generic libxtf (LGPL?)
- GRASS support via a new C module (without a libxtf)


- postgis import tool
- sqlite import tool
- stand alone command line converter to csv or xml ascii format
  (then shell script or python script importer to GIS)
- volunteer to hack support for it into MBSystems (see libxtf above)
  (then work on MBSystems - GRASS workflow code)

An XTF to ASCII conversion tool would be most welcome; we use Knudsen 3.5 kHz 
sounders quite a bit for sub-bottom profiling, and you're pretty much stuck 
working in Knudsen GUI to convert/process the data.

I work with MBSystems quite a bit; I think any sort of integration with Grass 
would be a great idea, and would be willing to test/bugcheck/document any new 
modules developed for it (sorry, can't contribute coding...yet).

I didn't realize the WIKI for Marine Geoscience existed...I'll try to think 
about any issues I've come across and post to it.

~ Eric.









  



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Copy raster from xy location to latlong

[Patton, Eric]

I have imported a remote sensing product from an HDF file into an XY
location. It is stored as a 1/4 degree pixel grid with 720 rows and 1440
columns. I would like to copy this raster to a new GRASS lat-long
(WGS84) location with a 1/4 degree resolution (90N, 90S, 180W, 180E).
Can someone please explain the best way to go about doing this?

As long as the two coordinate systems are the same, I don't think there's any
danger in using tar:

$ cd $GISDBASE/$MAPSET
$ tar cjvf rastername.tar */rastername
$cd $NEW_GISDBASE/$MAPSET
$ tar xjvf rastername.tar

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Multiple errors after lengthy absence from Grass 7

[Patton, Eric]

Just back from the field...wow, what a lot of changes that have been going on 
in the codebase! Catching up on Grass emails only took 7 hours ;)

After a fresh make distclean, and a lengthy svn update, Grass 7 fails to start 
up and exits with an error ERROR: Incompatible library version for module.

Checking the error.log, I see the following:

GRASS GIS compilation log
-
Started compilation: Wed Aug  6 16:09:24 ADT 2008
--
Errors in:
/usr/local/grass_trunk/display/d.colors
/usr/local/grass_trunk/general/g.setproj
/usr/local/grass_trunk/gui/wxpython/vdigit
/usr/local/grass_trunk/imagery/i.class
/usr/local/grass_trunk/imagery/i.ortho.photo/menu
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.2image
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.2target
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.camera
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.elev
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.init
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.rectify
/usr/local/grass_trunk/imagery/i.ortho.photo/photo.target
/usr/local/grass_trunk/imagery/i.points
/usr/local/grass_trunk/imagery/i.vpoints
/usr/local/grass_trunk/raster/r.le/r.le.setup
/usr/local/grass_trunk/raster/r.le/r.le.trace
/usr/local/grass_trunk/raster/r.support/modcats
/usr/local/grass_trunk/raster/r.support/modcolr
/usr/local/grass_trunk/raster/r.support/modhist
/usr/local/grass_trunk/raster/r.support/modhead
/usr/local/grass_trunk/raster/r.support/front
/usr/local/grass_trunk/raster/r.digit
--

Any ideas on where to start? Any particular module I should post the output 
from 'make'?

~ Eric.









___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.to.vect to selected locations only

[Patton, Eric]

Hamish:
random idea:
Maybe we could add a module of the day feed on the grass webpage with module 
name and label/description one-liner. I continue to find new modules many 
years after first using grass.

The same with me; not only am I discovering new modules, but also discovering 
flags present in old modules I've used for years that I wish I had known about 
years ago!

~ Eric.


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] help

[Patton, Eric]

y need to make a poligon, but i make the boundary then the centroid and i
dont know how to tell the program to make it a poligon.. can sombody help
me? thanks a lot!!

You probably need to enable 'snapping' within the v.digit module to make the 
polygon 
vertices coincident. See the attached screenshot showing where to set this on 
the 
v.digit Settings. 

Once you have snapping enabled, you may still have to manually move vertices 
that were 
digitzed prior to enabling snapping. Use the 'Move point, line, boundary, or 
centroid' 
tool on the v.digit interface (see attached screenshot). Once you move a vertex 
on top 
of another with this tool, the two should snap an become coincident. I usually 
make 
the snapping parameter around a few tens of meters for projected (UTM-style) 
projections. 

~ Eric.



attachment: Screenshot-settings.pngattachment: Move_Boundary.png___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] help

[Patton, Eric]

thank you a lot, im new in grass, im learning and i cant get the poligon
area, i think the procedure is to use the boundary button, make it close
then use the centroid option and then when i save the file and check the
info it says i  have a boundary and a centriod but no area, im i missing
some steps?

my snapping is the same as yours

Please keep all responses on the Grass mailing list so that others may 
participate/respond. Thanks...

Can you post a screenshot of your v.digit session? What happens when you 
manually
move two vertices together, do they snap? Can you post the output from v.info?

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Small tcltk fonts used in gis.m gui

[Patton, Eric]

I'm pretty sure something strange happened between my upgrade from Ubuntu 7.10 
to 8.04, but all applications that I use (there's not too many) that use tcl/tk 
as the gui toolkit have really small fonts being used. I have attached a 
screenshot of where this happens in the gis.m gui. Also attached is another 
example from a separate, custom gui I use in Grass; you can see the problem is 
much more apparant.

Does anyone know how I can re-configure the global font sizes used in tcl/tk?

Thanks,

~ Eric. 




attachment: Small_tcltk_font.pngattachment: Custom_app_example.png___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Error compiling vdigit support in wxgrass: make cannot find -lgdi

[Patton, Eric]

take a look at gui/wxpython/README

- 7 - DIGITIZATION TOOL

it is just a link to wxPython extension, still unsolved issue. You
need to create a symlink for now.

Martin

Thanks for the link. I created a symlink to the file in question:

$ cd /usr/local/lib
$ ls -rlt

lrwxrwxrwx 1 root root64 2008-04-23 09:15 libgdi.so - 
/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so

However, when I try to run the vdigit module in the map display window, I get 
an error with the following traceback:

Traceback (most recent call last):
  File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/to
olbars.py, line 182, in OnSelect

self.mapdisplay.AddToolbar(digit)
  File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/ma
pdisp.py, line 2399, in AddToolbar

self.digittoolbar = toolbars.DigitToolbar(self, self.Map,
self.tree)
  File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/to
olbars.py, line 298, in __init__

self.UpdateListOfLayers(updateTool=True)
  File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/to
olbars.py, line 831, in UpdateListOfLayers

self.combo = wx.ComboBox(self.toolbar[self.numOfRows-1],
id=wx.ID_ANY, value=value,
TypeError
:
'ToolBar' object is unindexable


~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Error compiling vdigit support in wxgrass: make cannot find -lgdi

[Patton, Eric]

oops, I introduced this bug yesterday when I was updating 'toolbars'
module, now should be fixed.

http://trac.osgeo.org/grass/changeset/31092

Martin

Thanks, I've tested it and it works great. Nice job!

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Error compiling vdigit support in wxgrass: make cannot find -lgdi

[Patton, Eric]

Hi,

I'm compiling vdigit support in wxpython Grass. I passed the --with-python and 
--with-wxwidgets flags during configure, with no errors.

make exits with one error:

snip
/usr/bin/ld: cannot find -lgdi
collect2: ld returned 1 exit status
make: *** [OBJ.x86_64-unknown-linux-gnu/_grass6_wxvdigit.so] Error 1

Does anyone know what library/package name this -lgdi refers to? In Ubuntu 
Synaptic, the only hit for gdi or python gdi is a package called 
python-egenix-mxbeebase, and installing this package doesn't seem to satisfy 
this dependency, after running make distclean and recompiling.

Any idea what's wrong?

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Problem removing mapsets in g.mapset

[Patton, Eric]

I can't seem to remove mapsets in g.mapsets using the new removemapset 
parameter. Ex:

$ g.mapsets -p
ED_Legacy_Data PERMANENT 2007006

$ g.mapsets rem=2007006
$ g.mapsets -p
ED_Legacy_Data PERMANENT 2007006

g.list is still fetching raster map names from the removed mapset as well:

$ g.list rast 
--
raster files available in mapset ED_Legacy_Data:
snip

raster files available in mapset PERMANENT:
snip

raster files available in mapset 2007006:
(all rasters follow)

~ Eric.







___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Orthorectification of Historic Aerial Photographs

[Patton, Eric]

May it be a stupid suggestion, but did you try to contact anyone at the
USGS ? perhaps they maintain data from these old times... (here in
France IGN is always helpful, and can provide answers to such historical
requests)

Vincent.

Similarly in Canada, provincial Department of Natural Resources frequently 
maintain documents from the original flight transects, sometimes going back 
several decades. I've managed to recover much aerial photo detail by contacting 
these agencies, including fiducial mark coordinates, camera make and focal 
length,
aircraft altitude, lens type, etc.

It's probably just a matter of tracking down the right federal agency to 
contact.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] db.connect database= parameter is null

[Patton, Eric]

I created a new location using today's svn source, and noticed that db.connect 
doesn't have its database parameter pre-populated with 
$GISDBASE/$LOCATION_NAME/$MAPSET/dbf as it used to; it is now blank. Possible 
bug? Would it possible to get the module to at least populate 
$GISDBASE/$LOCATION_NAME/$MAPSET for this parameter?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] RE: [GRASS-dev] db.connect database= parameter is null

[Patton, Eric]

Hi,

yes, see

http://trac.osgeo.org/grass/ticket/7

It seems to me that the VAR file should defined for newly created
mapset by default to avoid possible problems.

Martin

Thanks for the pointer. I'll hardcode my database paths for now.

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Can't connect to osgeo.org today

[Patton, Eric]

Has anyone had success synching their source code to the repositories on 
osgeo.org today? I can't update my source, nor connect to osgeo.org via 
the main website either.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Wich file format to transport (raster/ vector) datafrom a GRASSdb in to another computer's GRASS db? Why export vector data inshapefile for starspan/ OpenEV?

[Patton, Eric]

1.. if one needs to copy some GRASS raster data from his data base in
another computer's GRASS data base (same coordinate system of course),
then how? Where do for example the history files go? 

See r.pack/r.unpack in the Grass Add-ons. I use these scripts for moving
rasters around from computer to computer:

http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Raster_add-ons

The r.pack script uses a MatLab format file as an intermediary, and is 
apparently
a decent universal format for storing rasters in.

I understand (I think) the need to set-up properly a LOCATION and import
the data. But why isn't there a GRASS portable vector/ raster file
format?

I think r.in/out.ascii and v.in/out.ascii are designed for this? Not 100%
sure, but check the man pages for these two commands.

2. the same about vector data

See above.

3. Is it really necessaty to export in shapefiles when working with
starspan? If there is GRASS read-only support by OGR why is it
necessary to export?

I can't comment on Starspan; never used it.

What about OpenEV? If GDAL is built with GRASS support why can't it read
GRASS rasters?

I've wondered how to do this as well.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] occurrence of attributes in vektortable

[Patton, Eric]

how can i get a list of all different occurences in a column of an 
attributetable.

v.db.select map=mapname column=columnname | uniq (for vector with a connected 
attribute table)
db.select map=mapname column=columnname | uniq (for tables unattached to a 
vector)

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] occurrence of attributes in vektortable

[Patton, Eric]

On Fri, 2008-03-07 at 07:17 -0500, Patton, Eric wrote:
how can i get a list of all different occurences in a column of an 
attributetable.
 
 v.db.select map=mapname column=columnname | uniq (for vector with a 
 connected attribute table)


It doesn't work for me. What am I doing wrong?

Omit the -u flag from uniq.

Do the map and column parameters exist for db.select?

Whoops; my mistake. No, those parameters don't exist for db.select.
db.select uses table= instead of map=.

There also isn't a column parameter, so you'd have to use some SQL 
commands to get the column you need. 

Note you can omit the column heading name in the output in both db.select and 
v.db.select 
by using the -c flag:

db.select -c table=Matthew_2005013_Navigation | head -10
1|1860029|636162.13|5156960.89
2|186002910|636194.64|5157012.42
3|186002920|636229.43|5157064.57
4|186002930|636263.7|5157116.26
5|186002940|636297.62|5157169.61
...

~ Eric.




db.select table=TABLE 


 
 ~ Eric.

Nikos


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] loss of bash aliases

[Patton, Eric]

Hamish:
FWIW, my .grass.bashrc has:

.. /home/hamish/.alias
export HISTSIZE=3000

Thank you! I was trying to think of what that variable name was to extend
my mapset history beyond 500 records. 

# first GRASS instance gets set a low priority (because we can)
NUMGRASSES=`pgrep -c Init.sh`
if [ $NUMGRASSES -le 1 ] ; then
   renice +17 -p $$
else
   NICENESS=`echo $NUMGRASSES | awk '{printf(%0.f, 20 / $1)}'`
   renice +$NICENESS -p $$
fi

What is the result of this - that all Grass processes get a low priority
compared to the rest of the OS? 

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] loss of bash aliases

[Patton, Eric]

I have the following line in my .bashrc:

alias l='ls -lh --color=auto'

After I start a GRASS session this alias seems to go away. Is there anyway to 
respect user customization (i.e. .bashrc) when initializing GRASS? Or is this 
a user-related error?

Cheers,

Dylan

What happens if you copy your alias into ~/.grass_bashrc?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] loss of bash aliases

[Patton, Eric]

What happens if you copy your alias into ~/.grass_bashrc?

Sorry, that should have been ~/.grass.bashrc.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] RE: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

[Patton, Eric]

can you zoom a little bit so that the region is smaller than the raster
and then export with r.out.gdal to see whether it is still black?
Are you also getting warning about nulls in the data even if there  
are none?
I think there is a bug in the program (and it also does not let you set
the number of decimal digits so it produces numbers with large number
of digits that are useless).

thanks, Helena

Helena,

Zooming in to a smaller region than the raster doesn't change the results. I do 
get 
warnings about nulls, but it seems to make sense given the shape of the data 
I'm working
with relative to the region.

I exported a series of tiffs using r.out.gdal today, using type=Byte and 
type=UInt16. ArcGIS 9.2
was able to load the UInt16 tiffs, although very, very slowly. The 
elevation.10m raster from
Spearfish took about 2 minutes to load, and it was only 5.6MB in size. The long 
loading time
was due to the enormous size of the color table: 65,536 (2^16) colors. I can't 
imagine
how long it would take Arc to load a 200MB tiff with this many colors. It would 
probably crash.

All of the Byte tiffs were red. A look at the color table in Arc showed that 
all of the 255 colors were a repeating 
pattern of white-to-red (i.e., 0-31, 32-63, etc.), with no green or blue 
colors. 

I've never had a problem with the output from r.out.tiff, using it for 6 years 
now. I can view these
tiffs in every image viewer and GIS on both Linux and Windows. I imagine the 
reason for this is the relatively
simplified color tables in r.out.tiff tiffs? I would be great if there was a 
way to get 
georeferencing information installed in the headers of tiffs created from 
r.out.tiff. The output from 
r.out.gdal seems to be either way too detailed, or not mapped properly into a 
255 color space. 

Has anyone had success using the type=Byte in r.out.gdal to get consistently 
good output for use in other GIS?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.out.gdal Gtiff output does not preserve color tables

[Patton, Eric]

I'm using today's Grass 6.3.svn source, gdal 1.5.0.

$ gdalinfo --formats | grep GRASS
GRASS (ro): GRASS Database Rasters (5.7+)

In Spearfish60:
$ r.info -t elevation.10m
datatype=DCELL

$ g.region rast=elevation.10m -p
projection: 1 (UTM)
zone:   13
datum:  nad27
ellipsoid:  clark66
north:  4928000
south:  4914020
west:   590010
east:   609000
nsres:  10
ewres:  10
rows:   1398
cols:   1899
cells:  2654802

The following commands all produce tiffs that display completely black in 
off-the-shelf
image viewers in Ubuntu 7.10: (Eye of Gnome 2.20.1, GIMP 2.4.4)

$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte 
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte 
createopt=INTERLEAVE=PIXEL 
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte 
createopt=INTERLEAVE=PIXEL,PROFILE=GeoTIFF 
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte 
createopt=INTERLEAVE=PIXEL,PROFILE=BASELINE

These commands give a completely blank raster in the same image viewers:

$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 
createopt=INTERLEAVE=PIXEL
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 
createopt=INTERLEAVE=PIXEL,PROFILE=GeoTIFF
$ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 
createopt=INTERLEAVE=PIXEL,PROFILE=BASELINE

According to r.out.gdal manual, the type= parameter should be set to either 
Byte or UInt16 
to preserve the color table. I can't get either type to output anything useful. 
Using any other 
type causes r.out.gdal to complain that the color tables won't be preserved. 
What am I missing here?

Even the example from the r.out.gdal manual page produces an error and a tiff 
that does not display anything:

$ r.out.gdal in=elevation.10m out=ned_elev10m.tif type=Float64 
createopt=INTERLEAVE=PIXEL,TFW=YES
Exporting to GDAL data type: Float64
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
 100%
r.out.gdal complete.

Is a tiff without a color table even useful? I'd settle for a lossy, 
interpolated color table.

Normally I would just use r.out.tiff as a workaround, but I think this module 
ought to output 
georeferenced tiffs with sane color tables. In any case, I can't use the 
tiff-with-worldfile 
workaround; I need geotiffs with the projection info written into the header - 
*with* a color table.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] circular neighborhoods?

[Patton, Eric]

I was thinking about the circular neighborhoods that r.neighbors use.
How exactly are they shaped? I mean, in a 3x3 window, does the
circular one looks like a cross? and then it start to look more like a
circle as the size increases?

As far as I understand it,

A 3x3 window would look like this:

o-o-o
o-X-o
o-o-o

Where the 'X' is the current cell being processed. Similarly, a 5X5 window
would look like this:

o-o-o-o-o
o-o-o-o-o
o-o-X-o-o
o-o-o-o-o
o-o-o-o-o

r.neighbors will perform calculations on all the cells I've marked 'o' and and 
assign the output value to 'X', according to whatever method has been chosen 
(i.e., average, median, min, max, etc.).

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] circular neighborhoods?

[Patton, Eric]

So in a 3x3 example, neighborhoodSize=3, neighborhoodDistance=1, and your
first diagram has os where the mask is true.  The corners of the square
wouldn't be in the mask (as in Eric's 3x3), because those points would have 
the left hand side of the inequality equal to 2, making the mask false.

I haven't actually *tried* the code, but that is what the block of code in
gather.c for circular neighborhoods says it should be doing.

Thanks for the info - I wasn't even aware that r.neighbors could do that, as 
I've always used the square windows for my work. 

If I get a chance to test it out, I'll report back on what happening.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.drain documentation - updated

[Patton, Eric]

Stefano:
 On the other hand I can't understand why in the man page the section
 entitled BUG says: r.drain currently finds only the lowest point
 (the cell having the smallest category value) in the input file
 that can be reached through directly adjacent cells that are less
 than or equal in value to the cell reached immediately prior to it;
 therefore, it will not necessarily reach the lowest point in the
 input file. It currently finds pits in the data, rather than the
 lowest point present.. Why would a local search be a bug in this
 case? I think it should be like that by design...

Hamish:
It is like that by design so really a feature not a bug.
The man page should mention you could fill pits first with a module
like r.fill.dir or r.terraflow if you want that.
(the first is listed in the see also section but not explained AFAICS)

I've moved this section from 'Bugs' to 'Notes' to reflect the fact that it is
a feature of the module. There was already mention of using r.fill.dir and 
r.basins.fill for filling local pits, and I've included a mention of r.terraflow
in the 'Notes' section and under 'See Also'.

I added a section in 'Notes' warning the user about running r.drain on region 
boundary 
points, including the part Maris mentioned from the source code in his post. 
For now the warning
is under 'Notes', as I didn't really think is was a bug per se, more of a 
limitation of the module.
I added a hint about using g.region to tweak the region to allow r.drain to 
find an outlet away from
the region boundary.

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.describe Range output report type - superseded?

[Patton, Eric]

The docs for r.describe mention two kinds of reports that can be selected for 
output. I
can't find any evidence of this by experimenting with the module. Specifically, 
the docs mention
that a 'range' report can be generated, where negative min/max, zero, and 
positive min/max values are reported, and 
a 'Full List' report (which seems to be the program default output). Is the 
former just old
relic behavior that has been superseded and not updated in the docs? I wanted 
to be sure before
scrapping it from the manpage. I can't seem to get the program to output values 
the way this report mode is described.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.describe Range output report type -superseded?

[Patton, Eric]

excuse me if I a miss something but I get (GRASS6.2.2  6.3)

 r.describe SRTM3
READING [SRTM3 in nik] ... 100%
* -15 -13 -12 -10 thru 2285 2287-2314 2316-2318 2320-2325 2327-2330 2334
2342 
2344 2347 2349 2350 2357 2358 2361 2365 2375

and

r.describe -r SRTM3
READING [SRTM3 in nik] ... 100%
-15 thru -1
0
1 thru 2375
*

You're right, the range is output is only printed with the -r flag. I think I 
was trying to 
reproduce the same behavior without using the flag, and was getting confused in 
the process.

I'll update the docs accordingly. Thanks,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.drain documentation

[Patton, Eric]

I'm a bit confused about r.drain (I'm working with Debian's backport version
6.2.1). I have noticed that if you give as input in the coordinate
parameter a point that stands on the region's edge, r.drain won't move
from there: it would output a map with that same single point. Is this a
bug?
On the other hand I can't understand why in the man page the section
entitled BUG says: r.drain currently finds only the lowest point (the cell
having the smallest category value) in the input file that can be reached
through directly adjacent cells that are less than or equal in value to the
cell reached immediately prior to it; therefore, it will not necessarily
reach the lowest point in the input file. It currently finds pits in the
data, rather than the lowest point present.. Why would a local search be a
bug in this case? I think it should be like that by design...
I'm not too sure my understanding is correct. What do you think?
Thanks a lot in advance,
Stefano.

My short answer is I don't know; but I can try to have a look at the module and 
try to figure out what is happening...I've never used it before, so it will take
some trial-and-error to figure. Alternatively, if anyone listening is familiar 
with 
r.drain and can previde some hints, I'll certainly update the manpage.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] MASK seems to be ignored

[Patton, Eric]

 Checking the range of the raster I used for a mask in my
 r.mask command, it was 0-32767; so shouldn't r.mask in=MAP also create a 
 mask 
 where any non-null cell in the input raster exists?
 
 Here's the output from r.info for the mask I created using r.mask:

MASK maps usually look like this. It would be more useful to see the
r.info output for the original map.

r.info output for original map from which the mask was created:

$ r.info Diff_Nov2007_Oct2007_1m
 ++
 | Layer:Diff_Nov2007_Oct2007_1mDate: Mon Feb  4 14:10:04 2008|
 | Mapset:   PERMANENT  Login of Creator: epatton |
 | Location: Charlottetown|
 | DataBase: /home/epatton/Projects   |
 | Title: ( Diff_Nov2007_Oct2007_1m ) |
 | Timestamp: none|
 ||
 ||
 |   Type of Map:  raster   Number of Categories: 255 |
 |   Data Type:FCELL  |
 |   Rows: 1136   |
 |   Columns:  1249   |
 |   Total Cells:  1418864|
 |Projection: UTM (zone 20)   |
 |N:5119638S:5118502   Res: 1 |
 |E: 491292W: 490043   Res: 1 |
 |   Range of data:min = -2.80  max = 1.246000|
 ||
 |   Data Description:|
 |generated by r.mapcalc  |
 ||
 |   Comments:|
 |EC_Charlottetown_Bathy_November_2007_1m_fill -  |
 |EC_Charlottetown_Bathy_October_2007_1m  |
 ||
 ++


I'm assuming that the original does contain nulls (otherwise the
r.mapcalc method wouldn't do anything either). Is the original map a
reclass map?

Yes, the original contains nulls. The original map is not a reclass, but the 
cell
values do cross through zero, if that matters.

The r.mapcalc method creates a completely new map, while r.mask
creates a reclass map. A reclass map takes much less space, but is
affected by any changes to the underlying map (which can be good or
bad, depending upon what you want), and may be susceptible to a
different set of bugs, quirks and corner cases than a normal
(non-reclass) map.

Good to know; I'll use the r.mapcalc method as it seems a bit more immune to 
strangeness. I'll add some hints about this in the r.mask docs, too.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.mapcalc map arithmetic and raster data types

[Patton, Eric]

I've differenced two raster maps that are both type DCELL; (this in itself is 
strange, as I don't have any recollection of generating the input maps at this 
level of precision; FCELL would have been fine) the resulting raster map was an 
INT map whose cell values were all exactly zero. Why is this so? Is this 
because r.mapcalc math on two DCELL maps can't be represented on 32-bit 
architecture?  

I've tried using r.mapcalc's float function to convert the input maps to FCELL 
values, but the output remains DCELL:

# The input raster's vitals
r.info -rst BOF_ALLBATHY_Nov22_2007_10m
min=-278.542236
max=4.744175
nsres=10
ewres=10
datatype=DCELL

r.mapcalc BOF_ALLBATHY_Nov22_2007_10m_Float = 'BOF_ALLBATHY_Nov22_2007_10m'
 100%

# Output raster's vitals
r.info -rst BOF_ALLBATHY_Nov22_2007_10m_Float
min=-88.874466
max=-26.577181
nsres=10
ewres=10
datatype=DCELL

# The change in the raster range is because I've zoomed into a smaller subset 
of 
the original data to speed up calculations.

Shouldn't r.mapcalc's float function have produced an FCELL map?

~ Eric.


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] New script on wiki addons: v.select.region

[Patton, Eric]

Hi,

I've finished writing a script that solves the problem I was having in this 
thread:

http://thread.gmane.org/gmane.comp.gis.grass.user/20327/focus=20337

Namely, I wanted to create a list of vector maps within the current mapset 
whose boundaries fall within the current region (or within those of an existing 
vector), AND has vector objects (points, lines, areas, etc.) within the region 
as well. 

It's available in the vector section of the WIKI:
http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Vector_add-ons

Cheers,

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] MASK does not do it's work (?) with r.mapcalc --Again!

[Patton, Eric]

Nikos Alexandris wrote:
 Thanks for the important clarification.
 
 Do you think it would be useful to add this information in the manual
 of r.mask?

already added to the MASK section of the 2D-raster intro help page in
6.3svn. It makes some sense to add it to the r.mask help page too.
H

r.mask help page updated in svn trunk and grass63_release branch.

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.circle mult=4 does not work

[Patton, Eric]

I plotted circles on the map with r.circle mult=2 and it was fine.
But when I changed mult=4, it did not have any effect, the ccircles 
reminded as previous.
Befor recalculation I removed the old rasters.

Are there some limits with the multiplier?

Best regards

Seppo Kaitala

The mult parameter only changes the z-values of each output pixel, not its 
position. 
If you create different output maps with varying mult parameters and query each 
one
in turn, you'll see the size and extent of each output circle remain the same 
while 
their z-values vary according to each multiplier value.

I'll add a hint in the manual page about it.

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] r.circle mult=4 does not work

[Patton, Eric]

The mult parameter only changes the z-values of each output pixel, not its 
position. 
If you create different output maps with varying mult parameters and query 
each one
in turn, you'll see the size and extent of each output circle remain the same 
while 
their z-values vary according to each multiplier value.

I'll add a hint in the manual page about it.

Updated in svn TRUNK.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] When starting grass in text mode, why... ? (Question of minor importance)

[Patton, Eric]

could you try editing your $GISBASE/etc/Init.sh file and change the top
line to #!/bin/sh -x. That will show gratuitous script progress info
and hopefully tell us which command is causing that message.

Hamish

No need; I found the thread:

http://article.gmane.org/gmane.comp.gis.grass.user/14406/match=login+message+sudo

I can confirm that if you create a file called .sudo_as_admin_successful in any 
$LOCATION/$MAPSET,
the messages stop when Grass enters that location only. I have no idea what 
consequences might occur
if this file is automatically generated by Init.sh for every new mapset (maybe 
none?).

~ Eric.





___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Can't dissolve based on column?

[Patton, Eric]

Just a clarification...so it's the case that the column parameter in v.dissolve 
must always be of type integer, and *only* integer?

~ Eric.


-Original Message-
From: [EMAIL PROTECTED] on behalf of Nikos Alexandris
Sent: Wed 1/16/2008 3:41 PM
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Can't dissolve based on column?
 
Well... I suspected it had to do with the field type of the column
CODE_00.

Indeed... the column was TEXT.

After Daniels (Victoria) indications for a similar problem a change to
integer (using sqlitebrowser) solved the problem.

I suggest a clarification about that in the man page of v.dissolved.

Greets...

P.S. Thank you Daniel
On Wed, 2008-01-16 at 16:52 +0100,
[EMAIL PROTECTED] wrote:
 All I try to do is a dissolve... and for:
 
  v.dissolve input=clc00_clean output=clc00_dissolved
 col=CODE_00
 
 I get:
 
 DBMI-SQLite driver error:
 Cannot step:
 SQL logic error or missing database
 
 ERROR: Cannot fetch data
 ERROR: Unable to open vector map
 [EMAIL PROTECTED] on topology
level 2
 ERROR: Vector map clc00_dissolved not found in current
 mapset
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
-- 
Nikos Alexandris
.
Department of Remote Sensing  Landscape Information Systems
Faculty of Forestry  Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel.  +49 (0) 761 203 3697 / Fax.  +49 (0) 761 203 3701 / Skype: 
Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] i.ortho.photo crashes during photo.2target step

[Patton, Eric]

Hi,

I've been trying to orthorectify an aerial photo using i.ortho.photo. Everything
proceeds fine until I get to step 7 in the i.ortho.photo main menu where 
photo.2target
is called for placing GCP's on a raster in the target location within the 
monitor.

I've tried it both through gis.m and the command line, and in both cases 
i.ortho.photo
crashes when trying to load any raster I select to display in the monitor 
window, with the message
***stack smashing detected***: /usr/local/grass-6.3.svn/etc/photo.2target 
terminated

Has anyone encountered this error before?

~ Eric.



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] OT: metadata authoring tools

[Patton, Eric]

Two examples of FOSS metadata tools:
http://www.mdweb-project.org/:
http://geonetwork-opensource.org/:

Moritz

Thanks for the links, Moritz, I'll check these out.

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] OT: metadata authoring tools

[Patton, Eric]

Thanks Hamish, I will get my group working on this page as well. Perhaps we 
can contribute something back to the page in regards to what this ISO group 
is up to.

Cheers and thanks to everyone who made suggestions!

Dylan

I've updated the page with public domain definitions on metadata from the USGS,
as well as links to other standards and metadata authoring tools.

http://wiki.osgeo.org/index.php?title=Metadataredirect=no

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] (kein Betreff)

[Patton, Eric]

The width of a degree of longitude varies by latitude; meridians of longitude 
converge to
a single point at the poles. Latitude varies as well, although considerably 
less so, due to 
the rotation of the earth slightly squashing the poles, and bulging the Equator.

~ Eric.


-Original Message-
From: [EMAIL PROTECTED] on behalf of Gerald Nelson
Sent: Thu 12/13/2007 3:06 PM
To: 'Nikos Alexandris'; 'Michael Misun'
Cc: grass-user@lists.osgeo.org
Subject: RE: [GRASS-user] (kein Betreff)
 
I'm curious about the statement that Lat-Long is not good to do distance
measurements Someone else made a similar observation in a different
conversation recently too. I'm not a geographer so I'm probably missing
something but doesn't lat long just give you a point on the surface of the
earth and if you have two of these don't you more or less automatically know
the distance between them?

Regards, Jerry

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nikos Alexandris
Sent: Thursday, December 13, 2007 10:55 AM
To: Michael Misun
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] (kein Betreff)

Lat-Long is not good to do distance measurements!

Why don't you reproject your lines in a metric projection system and
check the distances again.

On Thu, 2007-12-13 at 14:03 +0100, Michael Misun wrote:
 hello everybody!
 i have a little problem:
 i want to set vertices on lines in a specified space (e.g. 2 km) in a lat
long coordinate system.
 i tried it with v.to.points -vi  dmax=0.03 and it works. the problem
is, that in the equatorial zone the space between the new added points is
about 1,7 km but up to the polzones the spacing is rather smaller and about
600 m!
 can anybody help me with this problem? a want to have an equal space for
all vertices on my polylines
 
 michael
-- 
Nikos Alexandris
.
Department of Remote Sensing  Landscape Information Systems
Faculty of Forestry  Environmental Sciences, Albert-Ludwigs-University
Freiburg
.
Tel.  +49 (0) 761 203 3697 / Fax.  +49 (0) 761 203 3701 / Skype:
Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] OT: metadata authoring tools

[Patton, Eric]

Dylan:
Sorry for the off-topic post. I am part of an ISO Metadata Editor Review 
committee over here, and was looking for some initial feedback on what 
various parties in the FOSS world use for metadata authoring, etc. There are 
some members of the group who are looking to building an extension to the 
BibTeX standard as a way of keeping the entire process in a text format, 
and integrateable  into standard document preparation techniques.

Metadata is a very big deal in our shop; there's been a big push in the last 
3-4 years to get all of our legacy data online and documented. Pretty 
much every bathymetry raster dataset we collect is destined for an ArcIMS 
public web portal, and so has to have FGDC-compliant metadata accompanying it. 

We use ArcGIS' ArcCatalog to write our metadata. I've been casting about for 
a FOSS metadata authoring tool, with not much luck. The USGS has
a couple tools called xtme/tkme which are used for metadata authoring. I tried 
installing them once, but never really had a lot of success with it. 

I'd be really interested in some kind of metadata scripting tool that uses 
LaTeX/BibTeX. Are they intending to write a new document class to integrate 
into LaTeX?

Metadata authoring is pretty much the only reason I need to use ArcGIS right 
now. 
If a free, open source alternative became available that was usable in a GRASS 
scripting
environment, that would be great! 

Dylan:
Any thoughts, suggestions, or stories would be appreciated. We are hoping to 
make a big impact on the formation of several federal (US) metadata authoring 
policies- with emphasis on open source software.

Good luck, and please keep the list updated on events. I'm definitely 
interested.

Cheers,

~ Eric.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user