Re: [GRASS-dev] g.extension global name error

[Martin Landa]

Hi,

2009/9/2 Martin Landa :
>> I am pretty much a python noob, so not sure where to start looking.
>>
>> Any ideas?
>
> Python script from trunk is suitable for GRASS 7. For GRASS 6 use
> shell script from GRASS Add-ons [1].

Fixed in r38942, anyway it's not guaranteed that python script from
GRASS 7 will work in GRASS 6.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.extension global name error

[Martin Landa]

Hi,

2009/9/2 Jeshua Lacock :

[...]

> I am pretty much a python noob, so not sure where to start looking.
>
> Any ideas?

Python script from trunk is suitable for GRASS 7. For GRASS 6 use
shell script from GRASS Add-ons [1].

Martin

[1] https://svn.osgeo.org/grass/grass-addons/general/g.extension

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Location Wizard Error

[Hamish]

Jeshua Lacock wrote:
> I just tried to use the wxpython location wizard with RC5
> to create a UTM, wgs84, N, zone 16 location and after
> entering the information and clicking the "Finish" button, I
> get the error:
> 
>     Error in command execution g.proj
> 
>     Execution failed: 'g.proj -c

that was a bug that slipped in to the rc5 release, please try
the latest 6.4.svn.

https://trac.osgeo.org/grass/ticket/654


Hamish





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

[GRASS-dev] Location Wizard Error

[Jeshua Lacock]

Greetings,

I just tried to use the wxpython location wizard with RC5 to create a  
UTM, wgs84, N, zone 16 location and after entering the information and  
clicking the "Finish" button, I get the error:


Error in command execution g.proj

Execution failed: 'g.proj -c proj4=+proj=utm +zone=16
+a=6378137.000 +rf=298.257223563 +no_defs
location=utm16'

Details:
Error: region for current mapset is not setrun "g.region"


Then if I hit enter or "OK", at the terminal I see:

jeshua:~ jeshua$ grass64
Cleaning up temporary files ...
Starting GRASS ...
Traceback (most recent call last):
  File "/Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/ 
gis_set.py", line 404, in OnWizard
gWizard = location_wizard.LocationWizard(self,  
self.tgisdbase.GetValue())
  File "/Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/ 
gui_modules/location_wizard.py", line 1742, in __init__

success = self.OnWizFinished()
  File "/Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/ 
gui_modules/location_wizard.py", line 1901, in OnWizFinished

success = self.Proj4Create(proj4string)
  File "/Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/ 
gui_modules/location_wizard.py", line 2031, in Proj4Create

p = gcmd.Command(cmdlist, stderr=None)
  File "/Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/ 
gui_modules/gcmd.py", line 358, in __init__

_("Error: ") + self.GetError()))
gui_modules.gcmd.CmdError


GRASS 6.4.0RC5 (newLocation):~ > Error: Unable to open file jeshua/test/newLocation/PERMANENT/WIND>: [Errno 2] No such file or  
directory: '/Users/jeshua/test/newLocation/PERMANENT/WIND'

wxGUI closed.


I know how to create a location manually, however, I thought someone  
might like know it doesn't look like it is working here.



Best,

Jeshua Lacock, Owner

phone: 208.462.4171

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

[GRASS-dev] Re: [GRASS GIS] #129: a fix for NVIZ site's dependency: elimination of sites lib dependency

[GRASS GIS]

#129: a fix for NVIZ site's dependency: elimination of sites lib dependency
--+-
  Reporter:  neteler  |   Owner:  neteler
  Type:  defect   |  Status:  assigned   
  Priority:  major|   Milestone:  6.4.0  
 Component:  NVIZ | Version:  svn-trunk  
Resolution:   |Keywords:  nviz   
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Comment (by helena):

 Replying to [comment:7 marisn]:
 > Replying to [comment:4 helena]:
 > > I am wondering whether this patch was tested for points with
 attributes functionality before it was applied? Maybe it fixed x draping
 but broke the scaling for attributes?
 > > I don't see anything obvious in the patch but it may be in how the
 vect library handles the attributes compared to sites
 > >
 > > Helena
 > Indeed this patch broke attribute dependent point rendering. I'm
 currently fixing parts of it, still I have problems understanding some
 parts of code and thus I would like to read some doc's how it should work:
 >  * seems like only 1 layer was supported
 yes, that is right - old sites map would have only one layer - I am not
 sure we need support for several layers for this functionality
 >  * what's an idea behind multiple attribute rows?
 I am not sure what you are refering to, there may be a paper about this
 functionality from the GRASS conference 2002 in Trento where this was
 introduced (there was a workshop as well).

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.extension global name error

[Jeshua Lacock]

Greetings,

I just checkout and compiled g.extension for RC5 here on Mac OS X.

If I just enter g.extension at the prompt, the GUI comes up. If I run  
it from the GUI or the command line I get this error:



(Tue Sep  1 19:11:25 2009)
g.extension -l svnurl=https://svn.osgeo.org/grass/grass-addons/grass7  
prefix=$(HOME)/.grass6/addons

Traceback (most recent call last):
 File
"/Library/OpenOSX/grass/grass-6.4.0RC5/scripts/g.extension",
line 237, in 
   sys.exit(main())
 File
"/Library/OpenOSX/grass/grass-6.4.0RC5/scripts/g.extension",
line 206, in main
   list_available_modules(options['svnurl'])
 File
"/Library/OpenOSX/grass/grass-6.4.0RC5/scripts/g.extension",
line 112, in list_available_modules
   grass.message(_('Fetching list of modules from GRASS-
Addons SVN (be patient)...'))
NameError: global name '_' is not defined
(Tue Sep  1 19:11:26 2009) Command finished (0 sec)


I am pretty much a python noob, so not sure where to start looking.

Any ideas?


Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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

[GRASS-dev] nviz with reclass files

[Helena Mitasova]

I just tried in on wingrass and it has the same problem - it actually  
drapes the raster over the surface but then it gets stuck.


Reclass rasters should probably go away in future releases but they  
are from the times
when disk space was valuable. Such rasters are derived by  
reclassification of another map

 and only the reclass table is stored - but if you accidentally
remove the original raster you practically lose your reclassed map as  
well.


landclass96 is a reclass of landuse96_28m which is in PERMANENT,
I will double check the original raster but it runs fine in GRASS63.
You are right that it would be useful to generate some other reclass  
maps to test

whether this is a data issue or a new bug in nviz,

thanks for trying it,

Helena



On Sep 1, 2009, at 5:36 PM, Jeshua Lacock wrote:



On Sep 1, 2009, at 7:48 AM, Helena Mitasova wrote:


can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes  
the problem.
It used to run, so I am not sure whether there is a problem with my  
data set

or with my version of GRASS (I am using William's grass64 binary).



Hi Helena,

I just did and I got the same error, so it is safe to say that it is  
not because of William's binaries.


I am not familiar with a "reclass raster", have you attempted to use  
another reclass raster?



Best,

Jeshua Lacock, Owner

phone: 208.462.4171



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

Re: [GRASS-dev] RC5 on Mac OS X

[William Kyngesburye]

On Sep 1, 2009, at 5:12 PM, Jeshua Lacock wrote:


That did the trick, thanks! Both wx-digit and wx-nviz both work now.

I *suspect* that means the wxpython GUI is not compatible with 2.8.10.

It works fine with 2.8.10.  I think your compiled wxpython didn't  
install correctly.  Try installing the latest wxpython binary package  
from wxpython.org.


-
William Kyngesburye 
http://www.kyngchaos.com/

"The beast is actively interested only in now, and, as it is always  
now and always shall be, there is an eternity of time for the  
accomplishment of objects."


- the wisdom of Tarzan





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

Re: [GRASS-dev] RC5 on Mac OS X

[William Kyngesburye]

On Sep 1, 2009, at 4:52 PM, Jeshua Lacock wrote:

Should _grass6_wxvdigit.so and _grass6_wxnviz.so be linked to  
libwx_mac? Because they are not, and that is where the symbol that  
_grass6_wxvdigit is failing to find lives.


Maybe.  I'm not quite sure about some of the finer details of linking  
libraries and loading extensions.  I think I went to the extreme and  
assumed wxlibrary symbols needed by the grass nviz module would be  
available because the wxpython modules would have loaded them.   
Really, if a module needs a symbol directly, it should link the  
library itself.


I'll look into it later, busy figuring out Snow Leopard stuff now...


- make sure you have /Library/Python/2.5/site-packages/ 
wxredirect.pth, maybe your wxpython build didn't install this for  
some reason. and make sure that you don't have any older wxpython  
junk in your site-packages.


Odd - I don't have that file in my source or in /Library:

find /usr/src/wxPython-src-2.8.10.1/ -name "*wxredirect*"
find /Library -name "*wxredirect*"

Both returns nothing.

I think it's generated during the install process, so you won't find  
it in the source.  Do you have any wx files at all in your site- 
packages?



-
William Kyngesburye 
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence


- the wisdom of Tarzan


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

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Sep 1, 2009, at 9:04 AM, William Kyngesburye wrote:

- the system wxpython meets the minimum requirements.  Try deleting  
your wxpython and reconfiguring GRASS to use the system wxPython.



That did the trick, thanks! Both wx-digit and wx-nviz both work now.

I *suspect* that means the wxpython GUI is not compatible with 2.8.10.


Cheers,

Jeshua Lacock, Owner

phone: 208.462.4171

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

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Sep 1, 2009, at 9:04 AM, William Kyngesburye wrote:

Which leads me to the question, how is launching it from the GUI  
(selecting 3D view) different than from the command line?


nviz from the terminal is opening the TclTk NVIZ.  In the Python GUI  
it's the wxPython NVIZ.


I see, that makes sense.

Should _grass6_wxvdigit.so and _grass6_wxnviz.so be linked to  
libwx_mac? Because they are not, and that is where the symbol that  
_grass6_wxvdigit is failing to find lives.



Are you using a wxpython binary install or your own compiled  
version?  I have not seen libwx_base_* as a normal OSX prefix for  
wx libraries, they're usually libwx_macud_*.


I looked at the instructions a bit better, and noticed that they  
recommend to use the "--enable-monolithic" flag on Mac OS X which  
creates the libraries that you are accustomed to.


But after making sure the old libs were deleted and rebuilding  
GRASS I still get the same exact errors.


So, you're saying that you did compile your own wxPython?  But then  
you rebuilt with the monolithic option?  Did you then distclean  
GRASS before recompiling it?


3 things to try:

- make sure you have /Library/Python/2.5/site-packages/ 
wxredirect.pth, maybe your wxpython build didn't install this for  
some reason. and make sure that you don't have any older wxpython  
junk in your site-packages.


Odd - I don't have that file in my source or in /Library:

find /usr/src/wxPython-src-2.8.10.1/ -name "*wxredirect*"
find /Library -name "*wxredirect*"

Both returns nothing.


- the system wxpython meets the minimum requirements.  Try deleting  
your wxpython and reconfiguring GRASS to use the system wxPython.


I did not know that wxpython was included with Mac OS X, thanks.

- try installing the latest wxPython binaries from the wxpython  
site, instead of compiling your own.


I will try both of these suggestions now...


Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Sep 1, 2009, at 7:48 AM, Helena Mitasova wrote:


can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the  
problem.
It used to run, so I am not sure whether there is a problem with my  
data set

or with my version of GRASS (I am using William's grass64 binary).



Hi Helena,

I just did and I got the same error, so it is safe to say that it is  
not because of William's binaries.


I am not familiar with a "reclass raster", have you attempted to use  
another reclass raster?



Best,

Jeshua Lacock, Owner

phone: 208.462.4171

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

Re: [GRASS-dev] Re: [GRASS GIS] #739: v.mkgrid parameter needs two values but is multiple=NO

[Markus Neteler]

On Tue, Sep 1, 2009 at 9:50 PM, Roger Bivand wrote:
> On Tue, 1 Sep 2009, GRASS GIS wrote:
>
>> #739: v.mkgrid parameter needs two values but is multiple=NO
...
>> here you need to use
>>
>> ... grid=paste(as.integer(100), as.integer(100), sep=",")
>
> No,
>
>> execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
>>   grid=paste(as.integer(100), as.integer(100), sep=",")))
>> Error in doGRASS(cmd, flags = flags, parameters = parameters) :
>> Parameter  does not have integer value
>
> because doGRASS() checks the type, and with c(as.integer(100),
>  as.integer(100)) would concatenate correctly with a comma.

I see (if possible, could we have the debug output of R?).

> The problem is in the wrong setting of grid->multiple as NO, which simply
> isn't examined from the command line. The wxpython GUI version has exactly
> the same problem.

For me it works in GRASS 6.5 wxGUI, also in the (current) 6.4.svn.

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

[GRASS-dev] Re: [GRASS GIS] #129: a fix for NVIZ site's dependency: elimination of sites lib dependency

[GRASS GIS]

#129: a fix for NVIZ site's dependency: elimination of sites lib dependency
--+-
  Reporter:  neteler  |   Owner:  neteler
  Type:  defect   |  Status:  assigned   
  Priority:  major|   Milestone:  6.4.0  
 Component:  NVIZ | Version:  svn-trunk  
Resolution:   |Keywords:  nviz   
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Comment (by marisn):

 Replying to [comment:4 helena]:
 > I am wondering whether this patch was tested for points with attributes
 functionality before it was applied? Maybe it fixed x draping but broke
 the scaling for attributes?
 > I don't see anything obvious in the patch but it may be in how the vect
 library handles the attributes compared to sites
 >
 > Helena
 Indeed this patch broke attribute dependent point rendering. I'm currently
 fixing parts of it, still I have problems understanding some parts of code
 and thus I would like to read some doc's how it should work:
  * seems like only 1 layer was supported
  * what's an idea behind multiple attribute rows?

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #739: v.mkgrid parameter needs two values but is multiple=NO

[Roger Bivand]

On Tue, 1 Sep 2009, GRASS GIS wrote:


#739: v.mkgrid parameter needs two values but is multiple=NO
--+-
 Reporter:  rsbivand |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new
 Priority:  normal   |   Milestone:  6.4.0
Component:  Vector   | Version:  6.4.0 RCs
Resolution:   |Keywords:
 Platform:  Unspecified  | Cpu:  Unspecified
--+-
Comment (by neteler):

Replying to [ticket:739 rsbivand]:
> When run from the command line, v.mkgrid map=xxx grid=100,50 works
(main.c, line 74), but in wxpython and execGRASS() in spgrass6 in R, the
--interface-description of grid->multiple = NO is respected, and only one
value can be passed. This then fails (in wxpython here) with:
>
>
> {{{
> v.mkgrid --overwrite map=grd grid=100
> ERROR: option  must be provided in multiples of 2
>You provided 1 items:
>100
> }}}


Yes, it must be 100,100 (the user has to specify two values).

> In R (using --interface-description):
>
>
> {{{
> > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
grid=as.integer(100)))
>
> ERROR: option  must be provided in multiples of 2
>You provided 1 items:
>100
>
> }}}

here you need to use

... grid=paste(as.integer(100), as.integer(100), sep=",")


No,


execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",

   grid=paste(as.integer(100), as.integer(100), sep=",")))
Error in doGRASS(cmd, flags = flags, parameters = parameters) :
  Parameter  does not have integer value

because doGRASS() checks the type, and with c(as.integer(100),
  as.integer(100)) would concatenate correctly with a comma.

The problem is in the wrong setting of grid->multiple as NO, which simply 
isn't examined from the command line. The wxpython GUI version has exactly 
the same problem.


Thanks for checking!

Roger



> or:
>
>
> {{{
> > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
grid=rep(as.integer(100), 2)))
> Error in doGRASS(cmd, flags = flags, parameters = parameters) :
>   Parameter  has multiple values
> }}}

Yes, because
{{{
> rep(as.integer(100), 2)
[1] 100 100
}}}

which is space but not comma separated. Indeed you need to use:

{{{
> paste(as.integer(100), as.integer(100), sep=",")
[1] "100,100"
}}}


> This conflicts with the single comma in grid->key_desc, which implies
two values, but grid->multiple = NO. The same seems to apply to box=. It
looks as though there is no conflict on the command line when multiple =
NO provided that the number of values agrees with # commas in key_desc
plus one, but that this does not work when --interface description is
used.

I don't think that this is a conflict: two comma separated values are
taken as one "string".
Instead, e.g. in r.series, multiple input maps are possible which are
multiple = YES, hence,
they are treated as separate tokens.




--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no

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

[GRASS-dev] Re: [GRASS GIS] #739: v.mkgrid parameter needs two values but is multiple=NO

[GRASS GIS]

#739: v.mkgrid parameter needs two values but is multiple=NO
--+-
  Reporter:  rsbivand |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Vector   | Version:  6.4.0 RCs
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by neteler):

 Replying to [ticket:739 rsbivand]:
 > When run from the command line, v.mkgrid map=xxx grid=100,50 works
 (main.c, line 74), but in wxpython and execGRASS() in spgrass6 in R, the
 --interface-description of grid->multiple = NO is respected, and only one
 value can be passed. This then fails (in wxpython here) with:
 >
 >
 > {{{
 > v.mkgrid --overwrite map=grd grid=100
 > ERROR: option  must be provided in multiples of 2
 >You provided 1 items:
 >100
 > }}}


 Yes, it must be 100,100 (the user has to specify two values).

 > In R (using --interface-description):
 >
 >
 > {{{
 > > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
 grid=as.integer(100)))
 >
 > ERROR: option  must be provided in multiples of 2
 >You provided 1 items:
 >100
 >
 > }}}

 here you need to use

 ... grid=paste(as.integer(100), as.integer(100), sep=",")

 > or:
 >
 >
 > {{{
 > > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
 grid=rep(as.integer(100), 2)))
 > Error in doGRASS(cmd, flags = flags, parameters = parameters) :
 >   Parameter  has multiple values
 > }}}

 Yes, because
 {{{
 > rep(as.integer(100), 2)
 [1] 100 100
 }}}

 which is space but not comma separated. Indeed you need to use:

 {{{
 > paste(as.integer(100), as.integer(100), sep=",")
 [1] "100,100"
 }}}


 > This conflicts with the single comma in grid->key_desc, which implies
 two values, but grid->multiple = NO. The same seems to apply to box=. It
 looks as though there is no conflict on the command line when multiple =
 NO provided that the number of values agrees with # commas in key_desc
 plus one, but that this does not work when --interface description is
 used.

 I don't think that this is a conflict: two comma separated values are
 taken as one "string".
 Instead, e.g. in r.series, multiple input maps are possible which are
 multiple = YES, hence,
 they are treated as separate tokens.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #739: v.mkgrid parameter needs two values but is multiple=NO

[GRASS GIS]

#739: v.mkgrid parameter needs two values but is multiple=NO
--+-
  Reporter:  rsbivand |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Vector   | Version:  6.4.0 RCs
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by rsbivand):

  * version:  unspecified => 6.4.0 RCs
  * component:  default => Vector

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #739: v.mkgrid parameter needs two values but is multiple=NO

[GRASS GIS]

#739: v.mkgrid parameter needs two values but is multiple=NO
-+--
 Reporter:  rsbivand |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 When run from the command line, v.mkgrid map=xxx grid=100,50 works
 (main.c, line 74), but in wxpython and execGRASS() in spgrass6 in R, the
 --interface-description of grid->multiple = NO is respected, and only one
 value can be passed. This then fails (in wxpython here) with:


 {{{
 v.mkgrid --overwrite map=grd grid=100
 ERROR: option  must be provided in multiples of 2
You provided 1 items:
100
 }}}


 In R (using --interface-description):


 {{{
 > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
 grid=as.integer(100)))

 ERROR: option  must be provided in multiples of 2
You provided 1 items:
100

 }}}

 or:


 {{{
 > execGRASS("v.mkgrid", flags="overwrite", parameters=list(map="grd",
 grid=rep(as.integer(100), 2)))
 Error in doGRASS(cmd, flags = flags, parameters = parameters) :
   Parameter  has multiple values
 }}}


 This conflicts with the single comma in grid->key_desc, which implies two
 values, but grid->multiple = NO. The same seems to apply to box=. It looks
 as though there is no conflict on the command line when multiple = NO
 provided that the number of values agrees with # commas in key_desc plus
 one, but that this does not work when --interface description is used.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] see the picture in vdigit with wingrass

[Quentin Page]

i all,

i try to work grass with windows (wingrass). the version is grass6.3.

I can see the picture but when I try to see the same picture in v.digit 
I have the white screen. i can see vector that i draw but not the 
pcture. i don't have error message. my instruction is


v.digit -n  map=name_of_vector bgcmd="d.rast pictu...@my_mapset"

thanks a lot
quentin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] RC5 on Mac OS X

[William Kyngesburye]

On Sep 1, 2009, at 4:42 AM, Jeshua Lacock wrote:

Note that I am able to start nviz by issuing the command in the  
terminal. The GUI loads, but my dem is not drawn when I hit "DRAW"  
- it is just blank.


Wow - how embarrassing! I did not have the region set right. So  
niviz is in-fact working for me.


Which leads me to the question, how is launching it from the GUI  
(selecting 3D view) different than from the command line?


Sorry for my monothread!



nviz from the terminal is opening the TclTk NVIZ.  In the Python GUI  
it's the wxPython NVIZ.


Are you using a wxpython binary install or your own compiled  
version?  I have not seen libwx_base_* as a normal OSX prefix for  
wx libraries, they're usually libwx_macud_*.


I looked at the instructions a bit better, and noticed that they  
recommend to use the "--enable-monolithic" flag on Mac OS X which  
creates the libraries that you are accustomed to.


But after making sure the old libs were deleted and rebuilding GRASS  
I still get the same exact errors.


So, you're saying that you did compile your own wxPython?  But then  
you rebuilt with the monolithic option?  Did you then distclean GRASS  
before recompiling it?


3 things to try:

- make sure you have /Library/Python/2.5/site-packages/wxredirect.pth,  
maybe your wxpython build didn't install this for some reason.  and  
make sure that you don't have any older wxpython junk in your site- 
packages.


- the system wxpython meets the minimum requirements.  Try deleting  
your wxpython and reconfiguring GRASS to use the system wxPython.


- try installing the latest wxPython binaries from the wxpython site,  
instead of compiling your own.


You could try forcing the Python you want by setting GRASS_PYTHON  
in your shell init, or in grass.sh.


I only have one copy of Python installed on this machine - the  
version that ships with Mac OS X. Would I set it to that?


No need to set it then.

-
William Kyngesburye 
http://www.kyngchaos.com/

"I ache, therefore I am.  Or in my case - I am, therefore I ache."

- Marvin


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

Re: [GRASS-dev] RC5 on Mac OS X

[Helena Mitasova]

Jeshua,

can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

 this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the  
problem.
It used to run, so I am not sure whether there is a problem with my  
data set

or with my version of GRASS (I am using William's grass64 binary).

thank you

Helena

On Sep 1, 2009, at 5:42 AM, Jeshua Lacock wrote:



On Sep 1, 2009, at 3:32 AM, Jeshua Lacock wrote:


On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:


On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from  
the map display), the GUI crashes and in the terminal reports:


dyld: lazy symbol binding failed: image not found for lazy  
pointer at 0x286d054

dyld: image not found for lazy pointer at 0x286d054



I just tried running GDB, but I was not able to find out any  
additional information. After it crashes it stops running so  
doing a backtrace just reveals that there is no stack.


Does anyone know what library that it is not finding might be?  
That might help narrow things down a bit.


Note that I am able to start nviz by issuing the command in the  
terminal. The GUI loads, but my dem is not drawn when I hit "DRAW"  
- it is just blank.


Wow - how embarrassing! I did not have the region set right. So  
niviz is in-fact working for me.


Which leads me to the question, how is launching it from the GUI  
(selecting 3D view) different than from the command line?


Sorry for my monothread!


Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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


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

Re: [GRASS-dev] GV_VOLUME: does it exist?

[Benjamin Ducke]

> AFAIU it is only really used by NVIZ so far for displaying 3D vector
> volumes*, but I think it is important to keep it in a state ready to
> be
> implemented :) 
> 
> [* e.g. v.in.dxf (not -f) -> nviz
> 
> http://bambi.otago.ac.nz/hamish/grass/screenshots/nyc3d_nviz3_midtown.png
> ]

Hmmm,

A quick "grep" for the entire GRASS source tree produces no indication
that any GRASS module (including NVIZ) actually does anything with
a GV_VOLUME geometry. It is defined as a symbol and the vector type
checking in routines in Vlib will parse it, that's about it.
The v.in.dxf module also seems to export GV_FACE objects only, not
GV_VOLUME. Of course, it is perfectly possible for a mesh of GV_FACEs
to completely circumscribe an enclosed space, in which case it really
should be a GV_VOLUME, I guess. But for the purpose of visualization
there is no real difference.

> 
> > Is there some actual Vect library level support for processing
> > such geometries or does GV_VOLUME just exist as a symbol for
> > completeness' sake? So far I could not spot it in the "type="
> > option of any GRASS module.
> 
> not much as far as I've found, but hopefully that will change one
> day.

I think I can confirm that now ;)

> better defining it's purpose would definitely help.
> 
> one question I've always had: do kernels exist as centroids within a
> closed volume (center of empty soccer ball), or one of the surface of
> every 3D face? (ie on on each hexagonal/pentagonal patch of the
> soccer
> ball)

Exactly! I have been getting headaches over that same question.
My current approach is to think about it like this:

A) One additional dimension adds one degree of freedom to geometric
representation. It includes lower dimensional representations, thus
3D geometries can assume more different roles than 2D or 1D and
(just like with 2D boundaries and "regular" 2D polylines)
-> We need some user-controllable semantics to set a specific role.

B) A GV_FACE is essentially the same as a 2D area,
but with 3D vertices. Its GV_KERNEL should lie on the
interior plane defined by its vertices. A GV_FACE has at least 3
vertices (a triangle).

C) A GV_VOLUME is a minimum of 4 GV_FACES that form a complete "hull"
in 3D space (since we do not have GV_NURB or similar, we cannot have
curved primitives and thus need at least 4 triangular GV_FACES to
make the most simple hull -- correct?). In this case, the GV_KERNEL
should be placed in the gravitational center of the entire volume.

>From a technological point of view, that differentiation may be
much less significant, though. At least as long as no actual 
operations are being performed on vector geometries that concern
volume. It's really purely semantics, just like boundary vs. line.

But if, like you said, we can agree on a set of semantics for 3D
primitives, then it should not be too hard to implement those
in all affected GRASS modules. Right now, I can only think of
v.hull which currently generates a 3D hull as n faces + 1 kernel.
It should be changed to 1 volume + 1 kernel.

A use case for n faces + n kernels would be a 3D TIN from elevation
points. But there should never be n faces + 1 kernel or 1 face + n kernels.

Once we have a consensus on these issues, GV_VOLUME needs to
be added to the basic modules, such v.info and the
import/export modules, I guess.

Cheers,

Ben


> 
> 
> Hamish


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

Re: [GRASS-dev] GV_VOLUME: does it exist?

[Hamish]

Benjamin Ducke wrote:
> could anybody enlighten me about the status of the GRASS 3D
> geometry type "GV_VOLUME"? I assume this is meant to be the equivalent
> of the 2D "GV_AREA", i.e. GV_KERNEL + GV_FACE(S)?

AFAIU it is only really used by NVIZ so far for displaying 3D vector
volumes*, but I think it is important to keep it in a state ready to be
implemented :) 

[* e.g. v.in.dxf (not -f) -> nviz
 http://bambi.otago.ac.nz/hamish/grass/screenshots/nyc3d_nviz3_midtown.png
]

> Is there some actual Vect library level support for processing
> such geometries or does GV_VOLUME just exist as a symbol for
> completeness' sake? So far I could not spot it in the "type="
> option of any GRASS module.

not much as far as I've found, but hopefully that will change one day.
better defining it's purpose would definitely help.

one question I've always had: do kernels exist as centroids within a
closed volume (center of empty soccer ball), or one of the surface of
every 3D face? (ie on on each hexagonal/pentagonal patch of the soccer
ball)


Hamish



  

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

[GRASS-dev] Re: [GRASS GIS] #734: wxGui sqlbuilder: a few bugs

[GRASS GIS]

#734: wxGui sqlbuilder: a few bugs
-+--
  Reporter:  hamish  |   Owner:  martinl   
  Type:  defect  |  Status:  assigned  
  Priority:  major   |   Milestone:  6.4.0 
 Component:  wxGUI   | Version:  6.4.0 RCs 
Resolution:  |Keywords:  sqlbuilder
  Platform:  Linux   | Cpu:  x86-64
-+--
Comment (by hamish):

 Replying to [comment:2 hamish]:
 >  - Columns and Values text boxes are now a bit too small,
 > only showing 1.5 column names + up/down slider. It would be
 > nice if it were big enough to at least show more of them.

 note that on an eeePC the default screen resolution is 1024x600,
 and the current window height for the SQL builder GUI (I get) is 525, so
 after you subtract 20px or so for the window manager taskbar(s) there
 isn't much room left for expansion. (The wx startup GUI is better than it
 used to be, but still the [enter grass] buttons are slightly crushed
 there)

 so it would be nice if gui widgets could be packed a little bit tighter
 and the starting window heights no taller than (say) 575px.
 (maybe smaller buttons for the = > < >= <=; move "Close dialog on apply"
 checkbox on to the same row as [Verify][Apply]; or rethink if full DB
 connection params are really needed at the top, or could swing down with a
 >,v or +,- expansion button?)


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7

[Soeren Gebbert]

Hello Hamish,

2009/9/1 Hamish 

> Hi,
>
> I get two errors compiling 6.5svn.
>
> The first is because lib/gmath  G_math_solvps() fails to return anything
> when it should return int.
>
> I think I fixed it with r38939, but please check to see if that is correct.
>  https://trac.osgeo.org/grass/changeset/38939


Thanks, thats absolutely correct.

>
>
> The second is in lib/external/ccmath, eigen() is used but not declared.
> I suppose it needs to be added to lib/external/ccmath/ccmath_grass.h, ??
>

I will have a look at it this evening.

>
> This can be caught if you add -Werror-implicit-function-declaration to
> your CFLAGS.


Oh, i forgot this.

Thanks,
Soeren

>
>
>
> cheers,
> Hamish
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #734: wxGui sqlbuilder: a few bugs

[GRASS GIS]

#734: wxGui sqlbuilder: a few bugs
-+--
  Reporter:  hamish  |   Owner:  martinl   
  Type:  defect  |  Status:  assigned  
  Priority:  major   |   Milestone:  6.4.0 
 Component:  wxGUI   | Version:  6.4.0 RCs 
Resolution:  |Keywords:  sqlbuilder
  Platform:  Linux   | Cpu:  x86-64
-+--
Comment (by hamish):

 Much better...!


 fine tuning / feedback:

  - Columns and Values text boxes are now a bit too small, only showing 1.5
 column names + up/down slider. It would be nice if it were big enough to
 at least show more of them.

  - it says "Add on double click" but actually it adds column name on
 single click. Or if you have a column name selected from the list and on
 the keyboard do up-down-up-down arrows it repeatedly adds those column
 names in the Query text box. Rename as "Add on double click as"? Before a
 little experimentation I find it hard to know what those radio buttons
 did. Possible to have a tooltip there?

  - shouldn't the base text end with "WHERE " ? (ok it shows up once I
 select a column name as "(*)values" but why not have it there to begin
 with?)

  - [Get sample],[Get all values] fail if the map is not in the current
 mapset (e.g. fie...@permanent). I had this running recently when it called
 the db.select directly; the trick is to pass db.* the full path to the
 database table the 4th column from 'v.db.connect -p', or use v.db.select.
 In the terminal shell window:
 {{{
 DBMI-DBF driver error:
 Table 'fields' doesn't exist.
 Error in db_open_select_cursor()

 ERROR: Fetching data from table  failed
 }}}


  - open SQL builder for fie...@permanent, click on Columns: _cat_, click
 on [Close]. you get this error in the main Layer Manager output tab:
 {{{
 Traceback (most recent call last):
   File "[$GISBASE]/etc/wxpython/gui_modules/sqlbuilder.py",
 line 321, in OnAddColumn

 if not self.btn_uniquesample.IsEnabled():
   File "/usr/lib/python2.5/site-
 packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14314, in
 __getattr__

 raise PyDeadObjectError(self.attrStr % self._name)
 wx._core
 .
 PyDeadObjectError
 :
 The C++ part of the Button object has been deleted,
 attribute access no longer allowed.
 }}}

  - uncheck "Close dialog on apply" by default? (match module GUI
 behaviour) It's just a bit surprising when it vanishes. Or change "Apply"
 to "Accept"?

  - Verify: show result in pop up window instead of status bar text? It's a
 bit less subtle, and the user did ask for reassurance. Or maybe better
 change the color of the text in the status bar:
  -- not verified: dark orange or dark yellow
  -- verified: changes to dark green
  -- invalid: changes to dark red.
 also as soon as you type/add more into the Query box it should reset to
 "not verified".


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #738: wxGUI: Attribute Table editor refresh & cosmetics

[GRASS GIS]

#738: wxGUI: Attribute Table editor refresh & cosmetics
-+--
 Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  minor|   Milestone:  6.4.0
Component:  wxGUI| Version:  svn-develbranch6 
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 Hi,

 just exploring the latest version of the wx Attribute manager + new
 sqlbuilder GUIs. It's really nice work Martin, congrats.

 some minor feedback/issues WRT the wx vector layer attribute manager GUI:
 (latest 6.5svn)

  - 'manage tables' tab: [Add] and [Rename] buttons fall off right side of
 GUI unless you stretch the window a bit wider manually.

  - column name: if you put in something silly like ";;" you get a nice
 pop-up window with a SQL error, but then it gets added to the list anyway.
 Luckily the GUI lets you drop that column from the list  (with another SQL
 "what are you talking about?" error popup).

  - "Column name: _"  : probably [Add] at the right makes this obvious
 so no action needed, but maybe put the word "new" in there?

  - if you add a new column then add another or drop another, you then have
 to hit [ok] to a number of errors saying it can't perform each of the
 prior actions because it already exists, etc. I guess the SQL queue needs
 to be flushed after each execution.

  - (trivial) if you add a new column the data-length value for int/double
 is not displayed until you close & reenter the attribute GUI.

  - after adding a new column, then going back to the 'Browse data' tab and
 clicking [Refresh], the new column doesn't show up. you can to close &
 reenter the attribute GUI to see/edit them. Right clicking on the column
 list in the 'manage tables' tab and selecting 'Reload' from the context
 meny makes the newly added columns disappear! (until you exit & reopen the
 attrib. manager)

  - Layer manger: right click on a vector layer entry the context menu has
 an option for "Show attribute data". Better to show off the power of the
 GUI by renaming that "Show/edit attribute data" ?


 All the while a stream of errors are printed to the Command Output tab in
 the layer manager, hopefully after the above are fixed they'll go away. If
 not I'll post them.


 cheers,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #724: wxGUI: Attribute Table editor lets you modify tables from other mapsets

[GRASS GIS]

#724: wxGUI: Attribute Table editor lets you modify tables from other mapsets
-+--
  Reporter:  hamish  |   Owner:  martinl   
  Type:  defect  |  Status:  closed
  Priority:  major   |   Milestone:  6.4.0 
 Component:  wxGUI   | Version:  svn-trunk 
Resolution:  fixed   |Keywords:  db, mapset
  Platform:  All | Cpu:  All   
-+--
Changes (by hamish):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Looks good in 6.5svn, relevant editing/deleting options are now greyed
 out.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Sep 1, 2009, at 3:32 AM, Jeshua Lacock wrote:


On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:


On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the  
map display), the GUI crashes and in the terminal reports:


dyld: lazy symbol binding failed: image not found for lazy pointer  
at 0x286d054

dyld: image not found for lazy pointer at 0x286d054



I just tried running GDB, but I was not able to find out any  
additional information. After it crashes it stops running so doing  
a backtrace just reveals that there is no stack.


Does anyone know what library that it is not finding might be? That  
might help narrow things down a bit.


Note that I am able to start nviz by issuing the command in the  
terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" -  
it is just blank.


Wow - how embarrassing! I did not have the region set right. So niviz  
is in-fact working for me.


Which leads me to the question, how is launching it from the GUI  
(selecting 3D view) different than from the command line?


Sorry for my monothread!


Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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

[GRASS-dev] GV_VOLUME: does it exist?

[Benjamin Ducke]

Hi all,

could anybody enlighten me about the status of the GRASS 3D
geometry type "GV_VOLUME"? I assume this is meant to be
the equivalent of the 2D "GV_AREA", i.e. GV_KERNEL + GV_FACE(S)?
Is there some actual Vect library level support for processing
such geometries or does GV_VOLUME just exist as a symbol for
completeness' sake? So far I could not spot it in the "type="
option of any GRASS module.

Happy coding,

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:


On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the  
map display), the GUI crashes and in the terminal reports:


dyld: lazy symbol binding failed: image not found for lazy pointer  
at 0x286d054

dyld: image not found for lazy pointer at 0x286d054



I just tried running GDB, but I was not able to find out any  
additional information. After it crashes it stops running so doing a  
backtrace just reveals that there is no stack.


Does anyone know what library that it is not finding might be? That  
might help narrow things down a bit.




Note that I am able to start nviz by issuing the command in the  
terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" -  
it is just blank.


Any ideas?


Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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

Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7

[Hamish]

Hi,

I get two errors compiling 6.5svn.

The first is because lib/gmath  G_math_solvps() fails to return anything
when it should return int.

I think I fixed it with r38939, but please check to see if that is correct.
  https://trac.osgeo.org/grass/changeset/38939



The second is in lib/external/ccmath, eigen() is used but not declared.
I suppose it needs to be added to lib/external/ccmath/ccmath_grass.h, ??

This can be caught if you add -Werror-implicit-function-declaration to
your CFLAGS.


cheers,
Hamish



  

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

Re: [GRASS-dev] RC5 on Mac OS X

[Jeshua Lacock]

On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the  
map display), the GUI crashes and in the terminal reports:


dyld: lazy symbol binding failed: image not found for lazy pointer  
at 0x286d054

dyld: image not found for lazy pointer at 0x286d054



I just tried running GDB, but I was not able to find out any  
additional information. After it crashes it stops running so doing a  
backtrace just reveals that there is no stack.


Does anyone know what library that it is not finding might be? That  
might help narrow things down a bit.



Thanks,

Jeshua Lacock, Owner

phone: 208.462.4171

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