Re: [GRASS-dev] gis.m command tool

2007-11-15 Thread Michael Barton



On 11/15/07 12:35 AM, "Hamish" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> In reviewing the gis.m man page, I notice this:
> 
>  Add command layer
> Adds a layer in which a GRASS GIS command or command list can be entered.
> For a command list use the pipe symbol as "|" as separator.
> For example:
> 
> 
>   d.rast soils | d.rast -o roads | d.vect streams col=blue
> 
> 
> Note that when an option of the command contains spaces, you need to
> escape them with the backslash ('\') character, for example:
> d.text.freetype text=Population\ density
> 
> 
> 
> any reason why that is not using ';' for the command sep? It would seem to
> make a lot more sense, match other bgcmd='s etc.
> 

Tradition.

Seriously, this is simply one of the small fragments of interface code that
has remained untouched since GRASS 5.1 and 5.7. A semi-colon makes a lot
more sense than a bar.

Michael
 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] doc 'upgrade' request for v.net.path

2007-11-15 Thread Michael Barton
Eric,

Here's something to add to the rapidly growing list. I was helping one of my
students work with vector networking, something I don't do a lot of. The
shortest path module, v.net.path is actually pretty easy to work with. But
the docs are so confusing that it took us quite awhile to figure out how to
specify the start and end point. There seems to be a fair amount of
extraneous stuff in the example that is not necessary to use the
module--maybe because most of this help file dates from the early days of
GRASS 5.7. It would be nice if someone who knows these modules well take a
look at them. I'm also copying the student, Andrea, in order to give her
your email because she is interested in helping develop documentation in
Spanish and has colleagues who might be able to help.

Here is a wish for someone else on the list...

Deciphering the docs for v.net.path, I figured out that the only ways to
specify start and end points  (AFAICT, but I could be missing something) are
1) to pipe them into the command or 2) put them into a text file and open
the text file with the command. Both seem overkill, since all you have to
give the command is the following string:

"1 [startcat] [endcat]"

...where [startcat] = the cat number of the starting node and [endcat]= the
cat number of the ending node. It is still unclear to me what the "1" is for
since it doesn't seem to apply to layer (i.e., the nodes in a network are
normally in layer 2).

It would seem a lot easier to simply have a "startend=" option built into
v.net.path that takes 2 cats separated by a comma.

Michael
______
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] doc 'upgrade' request for v.net.path

2007-11-16 Thread Michael Barton



On 11/16/07 5:48 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> On 15/11/07 16:30, Michael Barton wrote:
>> Eric,
>> 
>> Here's something to add to the rapidly growing list. I was helping one
>> of my students work with vector networking, something I don't do a lot
>> of. The shortest path module, v.net.path is actually pretty easy to work
>> with. But the docs are so confusing that it took us quite awhile to
>> figure out how to specify the start and end point. There seems to be a
>> fair amount of extraneous stuff in the example that is not necessary to
>> use the module--maybe because most of this help file dates from the
>> early days of GRASS 5.7. It would be nice if someone who knows these
>> modules well take a look at them. I'm also copying the student, Andrea,
>> in order to give her your email because she is interested in helping
>> develop documentation in Spanish and has colleagues who might be able to
>> help.
>> 
>> Here is a wish for someone else on the list...
>> 
>> Deciphering the docs for v.net.path, I figured out that the only ways to
>> specify start and end points  (AFAICT, but I could be missing something)
>> are 1) to pipe them into the command or 2) put them into a text file and
>> open the text file with the command. Both seem overkill, since all you
>> have to give the command is the following string:
>> 
>> "1 [startcat] [endcat]"
>> 
>> ...where [startcat] = the cat number of the starting node and [endcat]=
>> the cat number of the ending node. It is still unclear to me what the
>> "1" is for since it doesn't seem to apply to layer (i.e., the nodes in a
>> network are normally in layer 2).
> 
> 
> 1 is the id you wish to give to the resulting line. v.net.path
> automatically creates a category number, but it also creates an id
> column which contains this number.
> 
> This is linked to the fact that you are not limited to two points, i.e.
> two paths, but you can feed as many start and end points as you want to
> v.net.path.

Thanks very much for the clarification. This is far from clear in the docs.
Are the entries for each path (cat,start,path) to be separated by spaces or
a return in the text file?
 
1 start end 2 start end 3 start end...

OR

1 start end
2 start end
3 start end
...

> 
>> 
>> It would seem a lot easier to simply have a "startend=" option built
>> into v.net.path that takes 2 cats separated by a comma.
> 
> This would then limit the use to one path, unless you actually allow
> entry of multiples of 3 in the form id,start,end,id,start,end,...

Multiple entries of 3 separated by a comma or semicolon in a module option
(e.g., "startend=1 start end,2 start end,3 start end,...") would be no more
difficult to type and easier for non-unix types to understand than piping
the same info to the command (i.e., 1 start end 2 start end | v.net.path...)

Michael

\
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4

2007-11-16 Thread Michael Barton
William,

I just tried to install GRASS from the cvs. It fails on my OS X 10.4 machine
because it is hard coded to look for x11r7 (with OS X 10.5) instead of
x11r6. Can this be conditionalized to deal with 10.4 AND 10.5?

Michael
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4

2007-11-17 Thread Michael Barton



On 11/17/07 8:29 AM, "William Kyngesburye" <[EMAIL PROTECTED]> wrote:

> The install fails?  Or it fails to run?
> 
> The install doesn't care anything about what version of X11 you have.
> Running is already conditionalized for the X11 version.  What errors
> are you getting?

The compilation and install goes fine. It won't run wish. I did NOT install
a different TclTk, but am using the one I compiled from source several
months back, following directions in your README.

Here is the error.

/Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line 17:
/Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish: No such file or
directory
/Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line 17:
exec: /Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish: cannot
execute: No such file or directory

When I try to run wish, this is what I get

wish
dyld: Library not loaded: /usr/local/X11R7/lib/libX11.6.dylib
  Referenced from: /usr/local/lib/libtk8.4.dylib
  Reason: image not found
Trace/BPT trap


Michael

> 
> On Nov 17, 2007, at 12:55 AM, Michael Barton wrote:
> 
>> William,
>> 
>> I just tried to install GRASS from the cvs. It fails on my OS X 10.4
>> machine because it is hard coded to look for x11r7 (with OS X 10.5)
>> instead of x11r6. Can this be conditionalized to deal with 10.4 AND
>> 10.5?
>> 
>> Michael
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> [Trillian]  What are you supposed to do WITH a maniacally depressed
> robot?
> 
> [Marvin]  You think you have problems?  What are you supposed to do if
> you ARE a maniacally depressed robot?  No, don't try and answer, I'm
> 50,000 times more intelligent than you and even I don't know the
> answer...
> 
> - HitchHiker's Guide to the Galaxy
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4

2007-11-17 Thread Michael Barton
OK. Figured it out. But it needs to be fixed somewhere in the make systems I
think.

In both my previous compile (of a few weeks ago) and the one I tried last
night and today, a copy of wish8.4 is put into the $GISBASE/bin folder.

In my older version (which worked fine), apparently this is launched when
the GUI system is launched.

In the new version, it tries to launch a symlink named "wish" instead of the
embedded wish8.4. There is no such symlink and it tries to run another
symlink on my system that is NOT linked to the correct version of TclTk
(I'll fix that locally, but it should not affect GRASS).

When I created a symlink named "wish" for the embedded wish8.4 all works
well.

So what has changed? Something is calling wish instead of wish8.4, but I
don't know what.

Michael


On 11/17/07 9:24 AM, "William Kyngesburye" <[EMAIL PROTECTED]> wrote:

> On Nov 17, 2007, at 9:41 AM, Michael Barton wrote:
> 
>> Here is the error.
>> 
>> /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line
>> 17:
>> /Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish: No such
>> file or
>> directory
>> /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line
>> 17:
>> exec: /Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish:
>> cannot
>> execute: No such file or directory
>> 
>> When I try to run wish, this is what I get
>> 
>> wish
>> dyld: Library not loaded: /usr/local/X11R7/lib/libX11.6.dylib
>>  Referenced from: /usr/local/lib/libtk8.4.dylib
>>  Reason: image not found
>> Trace/BPT trap
>> 
> 
> Oh, that's bizarre.  Nothing to do with Leopard, though.  Things to
> check:
> 
> - Is there a wish, or any tcltk libraries, in the newly-installed
> GRASS app package?
> 
> - if not, were there any errors in the make (not install) stage?  try
> make inside the macosx folder.
> 
> - where is your tcltk installed (from those many months ago)?  /usr/
> local/tcltk, as in my instructions?  And is this what you configured
> GRASS with? (just checking)
> 
> - is there really a /usr/local/bin/wish and /usr/local/lib/libtcl and
> libtk?  Sounds like you may have installed some software that
> installed another copy of tcltk (which is broken because it's looking
> for /usr/local/X11R7).
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "Time is an illusion - lunchtime doubly so."
> 
> - Ford Prefect
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] cvs2svn: moving wxPython GUI code from Add-Ons repo to OSGeo SVN repo

2007-11-17 Thread Michael Barton
++1 for me. This will be a big help.

Michael


On 11/17/07 7:55 AM, "Martin Landa" <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> connected to the cvs2svn repository migration, I suggest to move
> wxPython GUI code from grasssvn.fbk.eu to the OSGeo SVN repository
> (before a final dumpstream will be prepared). I guess content of
> 'gui/wxpython' directory (strongly out-of-date) in CVS can be replaced
> by the source code available in GRASS Add-Ons repository.
> 
> Any objections?
> 
> Martin

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4

2007-11-17 Thread Michael Barton
Great. Thanks.

I'm visting Stanford to give a talk. I just installed GRASS on 2 iMacs and 2
laptops in the Archaeology Center spatial analysis lab.

Trying to get it on a colleague's PC laptop. This is trickier.

Michael


On 11/17/07 11:07 AM, "William Kyngesburye" <[EMAIL PROTECTED]> wrote:

> Doh!  I got a little carried away with a find-n-replace and messed up
> a sed replacement for the grass.sh script.  Fixed in cvs.  After
> recompile and install, you can delete that symlink for 'wish'.
> 
> On Nov 17, 2007, at 11:23 AM, Michael Barton wrote:
> 
>> OK. Figured it out. But it needs to be fixed somewhere in the make
>> systems I
>> think.
>> 
>> In both my previous compile (of a few weeks ago) and the one I tried
>> last
>> night and today, a copy of wish8.4 is put into the $GISBASE/bin
>> folder.
>> 
>> In my older version (which worked fine), apparently this is launched
>> when
>> the GUI system is launched.
>> 
>> In the new version, it tries to launch a symlink named "wish"
>> instead of the
>> embedded wish8.4. There is no such symlink and it tries to run another
>> symlink on my system that is NOT linked to the correct version of
>> TclTk
>> (I'll fix that locally, but it should not affect GRASS).
>> 
>> When I created a symlink named "wish" for the embedded wish8.4 all
>> works
>> well.
>> 
>> So what has changed? Something is calling wish instead of wish8.4,
>> but I
>> don't know what.
>> 
>> Michael
>> 
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "Time is an illusion - lunchtime doubly so."
> 
> - Ford Prefect
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4

2007-11-17 Thread Michael Barton



On 11/17/07 11:30 AM, "William Kyngesburye" <[EMAIL PROTECTED]> wrote:

> I'm curious: are you using a bindist-created installer package?  or
> building from source on each Mac?  I haven't heard any feedback from
> anyone on the bindist feature (it's what I use it to create my
> binaries for download).

I just put your most recent binaries on them (Sept. I think). I didn't have
much time. Everyone is very happy though.

Michael

> 
> On Nov 17, 2007, at 12:10 PM, Michael Barton wrote:
> 
>> Great. Thanks.
>> 
>> I'm visting Stanford to give a talk. I just installed GRASS on 2
>> iMacs and 2
>> laptops in the Archaeology Center spatial analysis lab.
>> 
>> Trying to get it on a colleague's PC laptop. This is trickier.
>> 
>> Michael
> 
> -
> 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
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] true type font question

2007-11-17 Thread Michael Barton
I'm trying to find out if this is a general issue, a Mac problem, or just a
problem with my stuff.

It used to be that whenever I displayed anything with text, it would default
to Romans unless I set the font to something else.

Now, displaying something with text displays NOTHING at all unless I
manually set the font globally (config menu) or in a particular module.

Is anyone else seeing this? Or is it just me?

Michael
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] true type font question

2007-11-18 Thread Michael Barton
In my case, fontcap is correctly produced, but nothing is selected
apparently.

Michael


On 11/18/07 4:52 AM, "Hamish" <[EMAIL PROTECTED]> wrote:

>> Michael Barton wrote:
>>> I'm trying to find out if this is a general issue, a Mac problem, or just
>>> a problem with my stuff.
>>> 
>>> It used to be that whenever I displayed anything with text, it would
>>> default to Romans unless I set the font to something else.
>>> 
>>> Now, displaying something with text displays NOTHING at all unless I
>>> manually set the font globally (config menu) or in a particular module.
>>> 
>>> Is anyone else seeing this? Or is it just me?
> 
> Moritz Lennert wrote:
>> We had the same problem in wingrass and it was due to etc/fontcap not
>> being correctly written during install (wrong path names). Running
>> g.mkfontcap in ant open grass session solved the problem.
> 
> this suggests a need for a fail-safe fallover to a default value (romans) on
> error, instead of setting the font to "".
> 
> 
> Hamish
> 
> 
> 
>   
> __________
> __
> Get easy, one-click access to your favorites.
> Make Yahoo! your homepage.
> http://www.yahoo.com/r/hs

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] select issue with wingrass

2007-11-18 Thread Michael Barton
If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
won't it then be available to all other gui modules?

That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
gui.tcl?

Michael


On 11/18/07 8:42 AM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Glynn Clements wrote:
> 
>>> I have advanced a little bit trying to debug this, although I have no idea
>>> why this has suddenly appeared and wasn't there all the time, and I'm,
>>> therefore, not sure that this is really the origin of the problem.
>>> 
>>> select.tcl uses both the GISDBASE and MAPSET env variables.
>> 
>> They aren't supposed to be environment variables.
>> 
>> I'm surprised that select.tcl has worked so far. It should be using
>> g.gisenv to get those values.
> 
> Ah; the reason it's been working so far is that both lib/gis/gui.tcl
> and gui/tcltk/gis.m/gm.tcl set them, e.g.:
> 
> if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {
> 
> Any other code which uses select.tcl will need to do likewise.
> 
> Use of env() is less than ideal (there's already enough confusion
> between GRASS variables and environment variables), but using separate
> variables would require changing a lot of "global" statements.

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] select issue with wingrass

2007-11-18 Thread Michael Barton



On 11/18/07 10:27 AM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

>> 
>> If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
>> won't it then be available to all other gui modules?
>> 
>> That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
>> gui.tcl?
> 
> If the array element isn't set, or if "global env" is missing, you
> would get an error from Tcl. That doesn't appear to be the case here.

The procedure in select.tcl DOES have global env...

proc GSelect_::create { element args } {
# main procedure for creating and managing selection window, which a
tree
# within a scrolling window.

global env id

...However, gui.tcl sets env(GISDBASE) etc outside of any procedure (i.e.,
runs these before any procedure). But there is no global env statement.
Maybe this is needed for Windows?

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] select issue with wingrass

2007-11-18 Thread Michael Barton



On 11/18/07 6:49 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Moritz Lennert wrote:
> 
>>> Ah; the reason it's been working so far is that both lib/gis/gui.tcl
>>> and gui/tcltk/gis.m/gm.tcl set them, e.g.:
>>> 
>>> if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {
>>> 
>>> Any other code which uses select.tcl will need to do likewise.
>>> 
>>> Use of env() is less than ideal (there's already enough confusion
>>> between GRASS variables and environment variables), but using separate
>>> variables would require changing a lot of "global" statements.
>> 
>> Changing above line to
>> 
>> if {[catch {set env(GISDBASE) [exec g.dirseps -g [exec g.gisenv
>> get=GISDBASE]]} error]} {
>> 
>> in lib/gis/gui.tcl seems to work for me. Can I commit ?
>> 
>> Should I also change this in gui/tcltk/gis.m/gm.tcl ?
> 
> Have you tried "file normalize"? If that works, it's preferable to
> spawning g.dirseps.

Is "file normalize" a TclTk thing or a Windows thing?

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: wingrass: dbf errors [was: Re: [GRASS-dev] select issue with wingrass]

2007-11-18 Thread Michael Barton
Moritz,

I hope that Javi can test. I'll try to find a student with a windows machine
to test your new binaries.

Michael


On 11/18/07 4:35 PM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> Michael Barton wrote:
>> Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
>> anything from the error message box or even make the box bigger so as to
>> show more of the error details. Is there a way to log this to send to you,
>> as it is quite long?
>> 
>> Interestingly, we are getting the *same* error produced by v.in.db when
>> running r.contour.
> 
> Both v.in.db and r.contour work for me.
> 
> Could you give me exact command lines and the data you used ?
> 
> Moritz

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] select issue with wingrass

2007-11-18 Thread Michael Barton
Given other discussions about forward and backward slashes, should
env(GISDBASE) be run through file normalize or not? What about env(GISBASE)?

Michael


On 11/18/07 6:49 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Moritz Lennert wrote:
> 
>>> Ah; the reason it's been working so far is that both lib/gis/gui.tcl
>>> and gui/tcltk/gis.m/gm.tcl set them, e.g.:
>>> 
>>> if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {
>>> 
>>> Any other code which uses select.tcl will need to do likewise.
>>> 
>>> Use of env() is less than ideal (there's already enough confusion
>>> between GRASS variables and environment variables), but using separate
>>> variables would require changing a lot of "global" statements.
>> 
>> Changing above line to
>> 
>> if {[catch {set env(GISDBASE) [exec g.dirseps -g [exec g.gisenv
>> get=GISDBASE]]} error]} {
>> 
>> in lib/gis/gui.tcl seems to work for me. Can I commit ?
>> 
>> Should I also change this in gui/tcltk/gis.m/gm.tcl ?
> 
> Have you tried "file normalize"? If that works, it's preferable to
> spawning g.dirseps.

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] select issue with wingrass

2007-11-19 Thread Michael Barton
Why would it not recognize

if {[catch {set env(GISDBASE) [file normalize [exec g.gisenv get=GISDBASE]]}
error]} {

???


On 11/19/07 3:01 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> if {[catch {set env(GISDBASE) [exec g.dirseps -g [exec g.gisenv
> get=GISDBASE]]} error]} {

__________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: wingrass: dbf errors [was: Re: [GRASS-dev] select issue with wingrass]

2007-11-19 Thread Michael Barton
One of my students, Isaac, just tried out your new binary. It fixes the
dbf.exe problem. Because he did an extract instead of dragging the GRASS
files to the desktop, he had no problems with the select issue.

However, NVIZ won't run. It gives a very "informative" SIGBRT error.

Michael


On 11/18/07 4:35 PM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> Michael Barton wrote:
>> Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
>> anything from the error message box or even make the box bigger so as to
>> show more of the error details. Is there a way to log this to send to you,
>> as it is quite long?
>> 
>> Interestingly, we are getting the *same* error produced by v.in.db when
>> running r.contour.
> 
> Both v.in.db and r.contour work for me.
> 
> Could you give me exact command lines and the data you used ?
> 
> Moritz

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


[GRASS-dev] 6.3.0 release - need to set default font

2007-11-24 Thread Michael Barton
I'm pretty sure that this was discussed briefly, but cannot find it in the
dev archives.

Sometime recently (past couple months), I've ended up without any default
font for GRASS in versions I compile, and have to set a font before I have
any text with barscales, legends, and the like.

The new TrueType font capabilities are great and much nicer than the old
default stroke fonts, but we should have *something* set as a default font
when GRASS starts up. This is a problem on Mac and Windows builds but may
not be showing up on Linux builds.

I can build something into the GUI's to set a default font on startup. But
it seems that this should be done in init.sh so as not to depend on the GUI
and, IMHO, would be even better as a GRASS variable that lives in
.grassrc6--so that whatever is set as a default font during a user session
stays there into future sessions.

In any case, we need something so that people don't fire up GRASS and wonder
why legends have no text.

Michael
__________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton
Paul,

You've ID'ed the proximate cause of the problem. See below.


On 11/25/07 4:47 AM, "Paul Kelly" <[EMAIL PROTECTED]> wrote:

> On Sat, 24 Nov 2007, Michael Barton wrote:
> 
>> I'm pretty sure that this was discussed briefly, but cannot find it in the
>> dev archives.
>> 
>> Sometime recently (past couple months), I've ended up without any default
>> font for GRASS in versions I compile, and have to set a font before I have
>> any text with barscales, legends, and the like.
>> 
>> The new TrueType font capabilities are great and much nicer than the old
>> default stroke fonts, but we should have *something* set as a default font
>> when GRASS starts up. This is a problem on Mac and Windows builds but may
>> not be showing up on Linux builds.
> 
> Does the problem go away if the fontcap file is regenerated:
> g.mkfontcap -o
> ?

Yes

> If so, this would be an issue with the install procedure not generating
> the fontcap file to match the local system and the installation location
> of GRASS. But I think there is more to it than that. I seem to remember
> someone said was the problem was *not* that romans wasn't being set as the
> default, but that there wasn't a properly matching entry for it in the
> fontcap file. What does
> d.font -L | grep romans
> say?

Prior to re-running g.mkfontcap, it comes up blank.

> 
> In general for actually using the fonts, if the path to the stroke fonts
> given in fontcap is wrong, it doesn't matter, as the library code
> currently ignores it and reconstructs the path based on the current
> GISBASE. However, the code that scans the fontcap checks the path given
> for each font there to see if it exists, and skips it if not, so I suspect
> that might be where the problem is. If so, re-running g.mkfontcap to
> generate the proper paths should fix it. As should the following patch
> (untested) but that is a bit of a hack and I would prefer the issue to be
> resolved by making sure the fontcap is current.

What is the best way to do this?

Also, where is the GRASS default font set to Romans?

Now that we have a system-wide fontcap, that normally would include nice
TrueType fonts, wouldn't it be better to first try to default to a TrueType
font and drop back to Romans only if that font couldn't be found?

e.g., whatever sets the default font first looks to see if a GRASS_FONT
variable is set in .grassrc6. If not, it scans fontcap for Helvetica, Vera
sans, Ariel, or some such nice san-serif TrueType font. If a font on a
restricted list of likely fonts is not found, it then defaults to the Romans
stroke font.

Michael




> 
> Paul
> 
> Index: lib/driver/parse_ftcap.c
> ===
> RCS file: /grassrepository/grass6/lib/driver/parse_ftcap.c,v
> retrieving revision 1.5
> diff -u -r1.5 parse_ftcap.c
> --- lib/driver/parse_ftcap.c11 May 2007 14:22:07 -  1.5
> +++ lib/driver/parse_ftcap.c25 Nov 2007 11:47:21 -
> @@ -56,7 +56,9 @@
>!= 6)
>  continue;
> 
> -   if (!font_exists(path))
> +   /* Don't check the path for stroke fonts as we
> reconstruct it
> +* from $GISBASE and don't need it to be correct here
> */
> +   if (type != GFONT_STROKE && !font_exists(path))
>  continue;
> 
>  fonts = (struct GFONT_CAP *)G_realloc(fonts,
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] [grass-code I][539] "Delete" or "remove" the name of g.remove?

2007-11-25 Thread Michael Barton
Maciek,

You are correct about the difference between the menu entry and command
name. This occurs in some other places as well.

In trying to shorten the menus and reduce nesting, I tried to find single
words (or a couple words) that would best convey the function to an audience
of users. Given the wording used in most software I've encountered, I felt
that more native English speakers who have some familiarity with computers
would recognize the function named "delete" better than one named "remove".

BUT this is based on a very non-systematic one-person review of software.

I have no problem with changing this if English-language users would better
recognize "remove". It should be whatever works best. The same thing goes
for translations into other languages. I've been less concerned with
matching menu entry names to GRASS module names (which have all kinds of
linguistically diverse histories) than trying to make GRASS functions
accessible to users.

>From my perspective, renaming the GRASS command to g.delete would make
better sense. However, we cannot do that until we switch to a new GRASS
version because it would break existing scripts.

Michael

On 11/25/07 2:13 AM, "Maciej Sieczka" <[EMAIL PROTECTED]> wrote:

> grass-dev@lists.osgeo.org wrote:
> 
>> In GRASS 6.3.cvs the g.remove command (under Manage maps
>> and volumes) is named "delete".
>> 
>> Shouldn't everything be either remove (g.remove, Remove a
>> map and the message in the Output GIS.m "Removing ... ")
>> or delete (g.delete, Delete a map and "Deleting ...) ?
> 
> Anybody minds renaming the "Delete" entry in gis.m into
> "Remove"?
> 
> Would "Remove" be really better?
> 
> Maciek

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton
On 11/25/07 12:13 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Michael Barton wrote:
> 
>> I'm pretty sure that this was discussed briefly, but cannot find it in the
>> dev archives.
>> 
>> Sometime recently (past couple months), I've ended up without any default
>> font for GRASS in versions I compile, and have to set a font before I have
>> any text with barscales, legends, and the like.
>> 
>> The new TrueType font capabilities are great and much nicer than the old
>> default stroke fonts, but we should have *something* set as a default font
>> when GRASS starts up. This is a problem on Mac and Windows builds but may
>> not be showing up on Linux builds.
>> 
>> I can build something into the GUI's to set a default font on startup. But
>> it seems that this should be done in init.sh so as not to depend on the GUI
>> and, IMHO, would be even better as a GRASS variable that lives in
>> .grassrc6--so that whatever is set as a default font during a user session
>> stays there into future sessions.
>> 
>> In any case, we need something so that people don't fire up GRASS and wonder
>> why legends have no text.
> 
> mon.select calls R_font(), with the font take from $GRASS_FONT, or
> "romans" if undefined.
> 
> LOC_init() (the initialisation function for immediate rendering) does
> likewise.
> 
> I've fixed the case where a named font cannot be found in the fontcap
> file (it sets the font to "romans" without using the fontcap file).

Thanks Glynn. This solves the immediate problem neatly.

What about making GRASS_FONT a GRASS variable rather than a shell variable?
I assume that it then could be set by g.gisenv (ending up in .grassrc6) and
consequently would then persist across working sessions.

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton



On 11/25/07 12:20 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Michael Barton wrote:
> 
>> Also, where is the GRASS default font set to Romans?
> 
> mon.select (display/d.mon/pgms/select.c) and LOC_init()
> (lib/raster/loc_io.c).
> 
>> Now that we have a system-wide fontcap, that normally would include nice
>> TrueType fonts, wouldn't it be better to first try to default to a TrueType
>> font and drop back to Romans only if that font couldn't be found?
>> 
>> e.g., whatever sets the default font first looks to see if a GRASS_FONT
>> variable is set in .grassrc6. If not, it scans fontcap for Helvetica, Vera
>> sans, Ariel, or some such nice san-serif TrueType font. If a font on a
>> restricted list of likely fonts is not found, it then defaults to the Romans
>> stroke font.
> 
> This doesn't belong in the libraries.
> 
> The only reason why there *is* a default font is so that there is
> (hopefully) always a current font.
> 
> The default is a stroke font because both the stroke fonts and the
> code which uses them should always be present. A system may not have
> any TrueType fonts and GRASS may have been built without FreeType
> support.

Granted. 

But, it would make GRASS output nicer if there was a way to scan for
FreeType support and search for a TrueType font to use before defaulting to
a stroke font.

If this is not feasible, making GRASS_FONT a GRASS variable instead of a
system variable would at least let a user set a nice font once, without
having to do it every time GRASS opens.

Currently, the only way to default to a nice font in all GRASS sessions is
to edit the .profile file--manually of course and from outside GRASS.
GRASS_FONT doesn't even register if put into the .grass.bash file. IMHO, it
would be good to set this GRASS behavior preference from inside GRASS, using
GRASS tools. It would certainly be more accessible to a wider group of GRASS
users in this way.

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton



On 11/25/07 2:43 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

> 
> Michael Barton wrote:
> 
>>>> Also, where is the GRASS default font set to Romans?
>>> 
>>> mon.select (display/d.mon/pgms/select.c) and LOC_init()
>>> (lib/raster/loc_io.c).
>>> 
>>>> Now that we have a system-wide fontcap, that normally would include nice
>>>> TrueType fonts, wouldn't it be better to first try to default to a TrueType
>>>> font and drop back to Romans only if that font couldn't be found?
>>>> 
>>>> e.g., whatever sets the default font first looks to see if a GRASS_FONT
>>>> variable is set in .grassrc6. If not, it scans fontcap for Helvetica, Vera
>>>> sans, Ariel, or some such nice san-serif TrueType font. If a font on a
>>>> restricted list of likely fonts is not found, it then defaults to the
>>>> Romans
>>>> stroke font.
>>> 
>>> This doesn't belong in the libraries.
>>> 
>>> The only reason why there *is* a default font is so that there is
>>> (hopefully) always a current font.
>>> 
>>> The default is a stroke font because both the stroke fonts and the
>>> code which uses them should always be present. A system may not have
>>> any TrueType fonts and GRASS may have been built without FreeType
>>> support.
>> 
>> Granted. 
>> 
>> But, it would make GRASS output nicer if there was a way to scan for
>> FreeType support and search for a TrueType font to use before defaulting to
>> a stroke font.
> 
> Automatically choosing a font is neither necessary nor desirable. This
> is up to the user.
> 
>> If this is not feasible, making GRASS_FONT a GRASS variable instead of a
>> system variable would at least let a user set a nice font once, without
>> having to do it every time GRASS opens.
> 
> They can set it in ~/.grass.bashrc.
> 
>> Currently, the only way to default to a nice font in all GRASS sessions is
>> to edit the .profile file--manually of course and from outside GRASS.
>> GRASS_FONT doesn't even register if put into the .grass.bash file.
> 
> Typo? Or are you actually editing the wrong file?

Nope. I was quite surprised when it had no effects. So I tried it a couple
of times--comparing effects between .profile and .grass.bashrc with exactly
the same syntax and checking in the manual to make sure it was the right
file. Works with .profile and doesn't with .grass.bashrc

In any case, the user still has to manually edit this file, which is
difficult in a non-Linux environment.

Most text editors on the Mac do not see files that begin with a "." and they
do not show up in the finder. (I think this degree of "protecting" a user is
silly, but that's the way it is).

Also, is this even a possibility with the native Windows GRASS?

> 
>> IMHO, it
>> would be good to set this GRASS behavior preference from inside GRASS, using
>> GRASS tools. It would certainly be more accessible to a wider group of GRASS
>> users in this way.
> 
> $GISRC isn't for user preferences, it's for session state.

Specifying a directory to serve as GISDBASE? Specifying GUI preference? I
suppose it's a matter of opinion, but I see selecting the default font as
being similar.

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton



On 11/25/07 3:42 PM, "Hamish" <[EMAIL PROTECTED]> wrote:

>> Michael Barton wrote:
>>> What about making GRASS_FONT a GRASS variable rather than a shell variable?
>>> I assume that it then could be set by g.gisenv (ending up in .grassrc6) and
>>> consequently would then persist across working sessions.
> 
> Glynn Clements wrote:
>> It should go into the user's environment, via ~/.grass.bashrc or one
>> of the standard shell initialisation scripts, like any other user
>> preference.
> 
> 
> my guess here is that Michael is not seeing the GRASS_FONT set in
> .grass.bashrc
> as he is working in a GIS.m lauched by init.sh *before* the grass terminal
> session (and thus .grass.bashrc) is run. If gis.m is run from the grass
> terminal prompt it should see it.

This seems to be the case (running TclTk or wxPython). If I quit the GUI and
then restart it from the terminal, I can see the results of setting
GRASS_FONT in .grass.bashrc.

Michael

> 
> If that is the case a previously mooted solution is to have a ~/.grassrc file
> which is sourced earlier in the game, before GUI subprocesses are spawned.
> 
> If we do add that, an idea of what a possible GRASS 7 ~/.grass/ dir might
> contain could help reduce migration issues later.
> 
> 
> Hamish
> 
> 
> 
>   
> __
> __
> Be a better sports nut!  Let your teams follow you
> with Yahoo Mobile. Try it now.
> http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-25 Thread Michael Barton



On 11/25/07 7:33 PM, "Hamish" <[EMAIL PROTECTED]> wrote:

> Michael Barton wrote:
>> In any case, the user still has to manually edit this file, which is
>> difficult in a non-Linux environment.
> 
> if you can find a command prompt on mac/linux and you use Bash:
>   echo "export GRASS_FONT=Vera" >> ~/.grass.bashrc

If someone knows enough to open a terminal and do something from the command
prompt, they can also use pico. But most Mac users are not really 'terminal
people'.

> 
> I'm not sure what the windows version would look like, something like:
>   echo "set GRASS_FONT=Vera" >> %HOME%\.grass.dosrc
> 
> (then .grass.dosrc would need to be sourced by init.bat)

Ditto for most Windows users

Michael

> 
> 
> Hamish
> 
> 
> 
>   
> __
> __
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] 6.3.0 release - need to set default font

2007-11-26 Thread Michael Barton



On 11/26/07 3:33 AM, "Glynn Clements" <[EMAIL PROTECTED]> wrote:

>> If we do add that, an idea of what a possible GRASS 7 ~/.grass/ dir might
>> contain could help reduce migration issues later.
> 
> A straightforward grassrc file should suffice for all preferences.
> grass.bashrc (and grass.cshrc etc) should be reserved for commands
> which have to be sourced by the interactive shell. We should really
> rename the grassrc6 file; it isn't an "rc" (run commands) file.
> grass.save would be more appropriate.

I agree with this. I understand the issues you bring up about the current
.grassrc6 file. It's sort of on the verge of becoming a combined rc and
preference file. So it would be a good idea to separate these functions. But
a preferences file is still a good idea, however it is implemented.

Michael

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] WinGrass testing results 6.3.0rc2

2007-11-26 Thread Michael Barton
Moritz and Benjamin,

I¹ve had a couple of students install the new winGRASS 6.3.0RC2 binary and
test it. The main remaining problems are (hopefully) easy to fix. See below.

The PROJ_SHARE variable is not set correctly
NVIZ won¹t launch (but did in a recent binary)

Other stuff seems to be working fine. Hopefully you¹ll be able to fix NVIZ
soon. The PROJ_SHARE issue should be easy.

Benjamin, any hope for the all-in-one *.exe package soon?

Michael
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> -- Forwarded Message
> From: Sean Bergin <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: Mon, 26 Nov 2007 13:06:57 -0700
> To: Michael Barton <[EMAIL PROTECTED]>
> Subject: WinGrass Problems
> 

> Michael,
> 
> Here are some of the problems Alex and I noticed:
> 
> The EPSG Code Browser tries to find the code at :
> /c/grass63RC2/share/proj/epsg  , and it should be
> C:/grass63RC2/share/proj/epsg  once entered, everything seems to work ok,
> although only once, if you restart it continues to look in the wrong place...
> 
> 
> NVIZ:  if NVIZ is run from the menu, you get child killed: Sigabrt / then a
> box that says dialog 0 opens.  If it is run from the map window, it crashes
> with chil process exited abnormally.
> 
> Sean
> 
> 
> 
> -- 
> Sean Bergin
> Ph.D. Student, Archaeology
> Graduate Assistant, Integrating Socio-Ecological Sciences Project
> School of Human Evolution and Social Change, ASU
> Tempe, AZ 85287-2402
> 
> [EMAIL PROTECTED]


-- End of Forwarded Message

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

[GRASS-dev] Re: WinGrass testing results 6.3.0rc2

2007-11-27 Thread Michael Barton



On 11/27/07 2:08 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

>> NVIZ won¹t launch (but did in a recent binary)
> 
> It works fine for me. Could you be a bit more specific (how do you
> launch it ? What is the error message ?) ?

Attempt to launch the NVIZ gui from the file menu
Attempt to automatically launch NVIZ from the map display toolbar button
Attempt to launch NVIZ from the gronsole command line
AFAIK there is no other way to launch this from GRASS for Windows.

In all cases there is either
1) TclTk error (child process aborted) or
2) Succinct Windows (?) error "Sigbert" or
3) Nothing

> 
>> Benjamin, any hope for the all-in-one *.exe package soon?
> 
> Are you speaking of an installer or of a self-extracting zip ?

Either one. The installer would be safer for most people (i.e., make sure
that all the pieces get installed in the correct places).

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] Re: WinGrass testing results 6.3.0rc2

2007-11-27 Thread Michael Barton



On 11/27/07 3:25 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> On 27/11/07 11:07, Paul Kelly wrote:
>> On Tue, 27 Nov 2007, Benjamin Ducke wrote:
>> 
>>>>> NVIZ won?t launch (but did in a recent binary)
>>> This can be somewhat tricky. For me, it fails to launch from within
>>>  the MSYS shell
> 
> I cannot confirm this: If I launch grass using /c/grass/bin/grass63
> (i.e. the shell launch script, not the .bat), nviz works perfectly for
> me, both from the gui and from the comand line.
> 
> (You have to change the definition of GISBASE from c:/ syntax to /c/
> syntax for it to work...I've corrected this in the wingrass6.3RC2
> package now

Not sure I understand this. How can you launch GRASS from a command line in
Windows? How do you get a command line to launch it from?

Probably a good idea to always run it from the *.bat file during development
to make sure it works that way, since that's how most people will run it.

> 
>>> as well as a sh.exe started via Window's cmd.exe.
> 
> Could you be more precise as to what exactly you are doing ? Do you
> launch grass via grass63.bat and then launch sh.exe within a running
> grass session ?
> 
>> 
>> That might be because the Msys shell doesn't recognise a .bat file
>> (in this case nviz.bat) as an executable and/or can't run it. What
>> happens if you add the GRASS scripts directory ($GISBASE/scripts
>> IIRC) to your path? Then it should pick up the nviz shell script that
>> will (should be???) installed in there.
> 
> If you run grass in msys you have to run the grass63 file which then
> calls Init.sh which sets the path to the scripts directory.

Again, I'm not sure how one actually does this. Is there a problem of which
gets launched first--mysys or TclTk?

Michael


__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] Re: WinGrass testing results 6.3.0rc2

2007-11-27 Thread Michael Barton
This helps a LOT. I think it also explains why NVIZ doesn't work (although I
don't understand why it DOES work on some systems). NVIZ is launched from a
script. IIRC, there at least some scripts get *.bat equivalents. Is/was this
the case for the script named "nviz"? Everyone here has installed mysys as
suggested in the README. But it is nice to know that it is NOT needed. The
problem then is that you can't run any of the scripts and some of these are
important.

If I understand you correctly, if we modify the grass63.bat to make sure
that it correctly indicates the location of mysys (we are just installing it
in the default location), scripts (including nviz) *should* run.

Another question for the general group here. I'm about to try to convince a
classroom lab manager to put this on the computers in the lab. Is there any
problem to installing mysys in a tightly managed lab environment? Are we
likely to run into any permission problems trying to run GRASS in such an
environment (i.e., where students do not have write permission outside their
own home directories)?

Michael


On 11/27/07 9:07 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> On 27/11/07 16:35, Michael Barton wrote:
>> 
>> 
>> On 11/27/07 3:25 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:
>> 
>>> On 27/11/07 11:07, Paul Kelly wrote:
>>>> On Tue, 27 Nov 2007, Benjamin Ducke wrote:
>>>> 
>>>>>>> NVIZ won?t launch (but did in a recent binary)
>>>>> This can be somewhat tricky. For me, it fails to launch from within
>>>>>  the MSYS shell
>>> I cannot confirm this: If I launch grass using /c/grass/bin/grass63
>>> (i.e. the shell launch script, not the .bat), nviz works perfectly for
>>> me, both from the gui and from the comand line.
>>> 
>>> (You have to change the definition of GISBASE from c:/ syntax to /c/
>>> syntax for it to work...I've corrected this in the wingrass6.3RC2
>>> package now
>> 
>> Not sure I understand this.
> 
> The above is for those who want to launch grass from within an msys
> terminal window.
> 
>> How can you launch GRASS from a command line in
>> Windows? How do you get a command line to launch it from?
> 
> For normal users (who do not work with msys as their terminal - you
> don't even need msys installed to do this):
> 
> - Open Start menu -> Run command -> type cmd.exe
> - In cmd.exe type c:\PathToGrassFolder\bin\grass63.bat
> - If you then want to launch the gis manager, type gis.m
> 
>> 
>> Probably a good idea to always run it from the *.bat file during development
>> to make sure it works that way, since that's how most people will run it.
> 
> Yes, but just as in the other environments you can run grass in windows
> as a command line or a gui application (or both).
> 
>> 
>>>>> as well as a sh.exe started via Window's cmd.exe.
>>> Could you be more precise as to what exactly you are doing ? Do you
>>> launch grass via grass63.bat and then launch sh.exe within a running
>>> grass session ?
>>> 
>>>> That might be because the Msys shell doesn't recognise a .bat file
>>>> (in this case nviz.bat) as an executable and/or can't run it. What
>>>> happens if you add the GRASS scripts directory ($GISBASE/scripts
>>>> IIRC) to your path? Then it should pick up the nviz shell script that
>>>> will (should be???) installed in there.
>>> If you run grass in msys you have to run the grass63 file which then
>>> calls Init.sh which sets the path to the scripts directory.
>> 
>> Again, I'm not sure how one actually does this. Is there a problem of which
>> gets launched first--mysys or TclTk?
> 
> Ok, let's clear things up a bit (and yes, I know I should do this on the
> wiki ASAP):
> 
> The general philosophy of the windows port of grass is that it should be
> a completely native application, with no need of any kind of *nix
> emulation. For most of grass this is now possible, which means all you
> need to install to run grass is tcltk and my binary package. Nothing
> else, not even msys !
> 
> On that basis you can launch grass either by clicking on the grass63.bat
>   file or by launching it from the command line as explained above. As
> in other environments, the choice of GRASS_GUI is stored in the
> .grassrc6 file which is stored by default in the %USERPROFILE%
> directory, which normally defaults to C:\Documents and
> Settings\username. So, you can change GRASS_GUI to text and grass will
> open in text mode, even if you click on the grass6

Re: [GRASS-dev] Re: WinGrass testing results 6.3.0rc2

2007-11-27 Thread Michael Barton
Benjamin,

If you need a place to put this, I can put it on my server here. I'd love to
have this (at least a complete GRASS setup) to pass out to my students next
semester. We start before the middle of January.

Michael


On 11/27/07 2:49 AM, "Benjamin Ducke" <[EMAIL PROTECTED]>
wrote:

>> 
>>> NVIZ won¹t launch (but did in a recent binary)
> This can be somewhat tricky. For me, it fails to launch from within
> the MSYS shell as well as a sh.exe started via Window's cmd.exe.
> 
> It does start, however when run directly through cmd.exe and also
> starts up fine from the gis.m menu.
> 
>> 
>> It works fine for me. Could you be a bit more specific (how do you
>> launch it ? What is the error message ?) ?
>> 
>>> Benjamin, any hope for the all-in-one *.exe package soon?
> 
> Yes, sort of. I am making good progress and have succeeded in setting
> up a complete compilation environment for GRASS and QGIS on MinGW.
> Hopefully, I will be able to push a first beta version onto some
> webserver by the end of the year or early next year.
>> 
>> Are you speaking of an installer or of a self-extracting zip ?
> 
> I will look into creating an installer for Windows. This should not
> be hard to do. In fact, I think Windows provides pretty much everything
> you need for a .exe or .msi installer package.
> 
>> 
>> Moritz
> 
> Benjamin
> 
>> 
>> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


Re: [GRASS-dev] [grass-code I][544] Map Display crashes when zooming (too much) in!

2007-11-29 Thread Michael Barton
I just tried this with cvs compiled from an update of this morning and had
no problems.

In normal mode, if you zoom to less than 1 raster cell, a TclTk message box
pops up saying you've exceeded the maximum zoom.

In explore mode, you can zoom to much less than 1 raster cell.

In neither case did I get a TclTk error like the one below.

I did wait until a map  was completely displayed before trying to zoom
again.

I tried this on a Mac PPC G5, with OS X 10.4.11.

Has anyone else had this problem?

Michael


On 11/28/07 5:01 PM, "grass-dev@lists.osgeo.org" 
wrote:

> code I item #544, was opened at 2007-11-29 00:01
> Status: Open
> Priority: 3
> Submitted By: Nikos Alexandris (nikosa)
> Assigned to: Nobody (None)
> Summary: Map Display crashes when zooming (too much) in!
> Issue type: other bug
> Issue status: None
> GRASS version: CVS HEAD
> GRASS component: display
> Operating system: Linux
> Operating system version: Ubuntu 7.10
> GRASS CVS checkout date, if applies (YYMMDD):
> 
> 
> Initial Comment:
> .The Display Crashes when zooming in too much in a specific point (in a raster
> map) displayed in Map Display.
> 
> .First error message is: Error setting region: child process exited abnormally
> 
> .Second error message (after pressing ok): Error: can't read
> "parts(projection)"...
> 
> can't read "parts(projection)": no such variable
> can't read "parts(projection)": no such variable
> while executing
> "regexp -nocase {^.* (\(.*\))} $parts(projection) trash end"
> (procedure "MapCanvas::runprograms" line 46)
> invoked from within
> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
> (procedure "MapCanvas::drawmap" line 38)
> invoked from within
> "MapCanvas::drawmap $mon"
> (procedure "MapCanvas::display_server" line 9)
> invoked from within
> "MapCanvas::display_server"
> ("after" script)
> ---
> 
> .Don't know if g.region -p is necessary to report... (just for any case):
> 
> GRASS 6.3.cvs (Peloponnese_HGRS87):~/> g.region -p
> projection: 99 (Transverse Mercator)
> zone:   0
> datum:  towgs84=-199.87,74.79,246.62
> ellipsoid:  grs80
> north:  4255230
> south:  3994272
> west:   226090
> east:   468372
> nsres:  249.95977011
> ewres:  250.03302374
> rows:   1044
> cols:   969
> cells:  1011636
> [Raster MASK present]
> 
> 
> 
> --
> 
> You can respond by visiting:
> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=544&group_id=21
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


Re: [GRASS-dev] [grass-code I][544] Map Display crashes when zooming (too much) in!

2007-11-29 Thread Michael Barton
What I was thinking of doing was simply having the GUI do a return to
previous zoom + display after showing the message about zooming in too far.

Michael


On 11/29/07 12:54 PM, "Maris Nartiss" <[EMAIL PROTECTED]> wrote:

> Hi Michael and others.
> 
> To reproduce this problem more easily than with Spearfish dataset just
> create new location with parameters like in initial bug report.
> For some reason at some point variables $mapwd or $mapht get values
> like "1.8912764e-10" or similar and then are not catched by $mapwd==0
> comparison. I attached small quick hack around problem that limits
> zoom-in to half of cell size (resolution). It fixes this problem but
> may cause problems for users without sane resolution like after
> creating new location from vector data source. Still requiring sane
> resolution for location is not worse case scenario. Or should we limit
> zoom-in till mapwd is smaller than 2?
> 
> 
> Maris.
> 
> 2007/11/29, Michael Barton <[EMAIL PROTECTED]>:
>> I just tried this with cvs compiled from an update of this morning and had
>> no problems.
>> 
>> In normal mode, if you zoom to less than 1 raster cell, a TclTk message box
>> pops up saying you've exceeded the maximum zoom.
>> 
>> In explore mode, you can zoom to much less than 1 raster cell.
>> 
>> In neither case did I get a TclTk error like the one below.
>> 
>> I did wait until a map  was completely displayed before trying to zoom
>> again.
>> 
>> I tried this on a Mac PPC G5, with OS X 10.4.11.
>> 
>> Has anyone else had this problem?
>> 
>> Michael
>> 
>> 
>> On 11/28/07 5:01 PM, "grass-dev@lists.osgeo.org" 
>> wrote:
>> 
>>> code I item #544, was opened at 2007-11-29 00:01
>>> Status: Open
>>> Priority: 3
>>> Submitted By: Nikos Alexandris (nikosa)
>>> Assigned to: Nobody (None)
>>> Summary: Map Display crashes when zooming (too much) in!
>>> Issue type: other bug
>>> Issue status: None
>>> GRASS version: CVS HEAD
>>> GRASS component: display
>>> Operating system: Linux
>>> Operating system version: Ubuntu 7.10
>>> GRASS CVS checkout date, if applies (YYMMDD):
>>> 
>>> 
>>> Initial Comment:
>>> .The Display Crashes when zooming in too much in a specific point (in a
>>> raster
>>> map) displayed in Map Display.
>>> 
>>> .First error message is: Error setting region: child process exited
>>> abnormally
>>> 
>>> .Second error message (after pressing ok): Error: can't read
>>> "parts(projection)"...
>>> 
>>> can't read "parts(projection)": no such variable
>>> can't read "parts(projection)": no such variable
>>> while executing
>>> "regexp -nocase {^.* (\(.*\))} $parts(projection) trash end"
>>> (procedure "MapCanvas::runprograms" line 46)
>>> invoked from within
>>> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
>>> (procedure "MapCanvas::drawmap" line 38)
>>> invoked from within
>>> "MapCanvas::drawmap $mon"
>>> (procedure "MapCanvas::display_server" line 9)
>>> invoked from within
>>> "MapCanvas::display_server"
>>> ("after" script)
>>> ---
>>> 
>>> .Don't know if g.region -p is necessary to report... (just for any case):
>>> 
>>> GRASS 6.3.cvs (Peloponnese_HGRS87):~/> g.region -p
>>> projection: 99 (Transverse Mercator)
>>> zone:   0
>>> datum:  towgs84=-199.87,74.79,246.62
>>> ellipsoid:  grs80
>>> north:  4255230
>>> south:  3994272
>>> west:   226090
>>> east:   468372
>>> nsres:  249.95977011
>>> ewres:  250.03302374
>>> rows:   1044
>>> cols:   969
>>> cells:  1011636
>>> [Raster MASK present]
>>> 
>>> 
>>> 
>>> --
>>> 
>>> You can respond by visiting:
>>> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=544&group_id=21
>>> 
>> 
>> __
>> Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics and Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


Re: [GRASS-dev] [grass-code I][544] Map Display crashes when zooming (too much) in!

2007-11-29 Thread Michael Barton
I just committed a fix so that after displaying the message box informing
the user that the max zoom limit has been exceeded, the display rolls back
to the previous zoom.

Michael


On 11/29/07 1:50 PM, "Hamish" <[EMAIL PROTECTED]> wrote:

>>> code I item #544, was opened at 2007-11-29 00:01
>>> Summary: Map Display crashes when zooming (too much) in!
> 
> Michael Barton wrote:
>> Has anyone else had this problem?
> 
> 
> ISTR this same issue was near the first gis.m bug report we ever had, and the
> first of the "child returned an error" series. There'll be a long lost thread
> somewhere in the archives
> 
> 
> Hamish
> 
> 
> 
>   
> __
> __
> Get easy, one-click access to your favorites.
> Make Yahoo! your homepage.
> http://www.yahoo.com/r/hs

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


[GRASS-dev] wingrass and nviz

2007-12-01 Thread Michael Barton
One of my RA's got nviz to work, after reading your posts about scripts. But
it required putting the grass directory INSIDE of the mysys directory, since
mysys seems to have trouble finding locations above the level of it root
directory.

Have any of you found this?

Michael
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] [grass-code I][544] Map Display crashes when zooming (too much) in!

2007-12-01 Thread Michael Barton



On 12/1/07 4:12 AM, "Maciej Sieczka" <[EMAIL PROTECTED]> wrote:

> After Michael's fix Nikos asked a question in the tracker.
> Maybe someone would like to address it. Please read below.
> 
>> Comment By: Nikos Alexandris (nikosa)
>> Date: 2007-11-30 01:50
>> 
>> Message:
>> I just tested and the "Max zoom in reached" message does the job  ;-)  --
>> Thank you!
>> 
>> Yet, I would like to share my skepsis about this:
>> 
>> a. "Maximum zoom-in reached." would be too long for a message (instead of
>> "Max")?

I'm not quite clear here. Do you want to use the word "maximum" instead of
"max"?

>> b. Is it difficult to make it go back automatically to the last visible
>> zoom-in status instead of having to do it manually?

That's what it does on my system now. What does it do on your system?

> 
> Maciek

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] [grass-code I][544] Map Display crashes when zooming (too much) in!

2007-12-01 Thread Michael Barton



On 12/1/07 8:45 AM, "Nikos Alexandris"
<[EMAIL PROTECTED]> wrote:

> 
> On Sat, 2007-12-01 at 08:39 -0700, Michael Barton wrote:
>> 
>> 
>> On 12/1/07 4:12 AM, "Maciej Sieczka" <[EMAIL PROTECTED]> wrote:
>> 
>>> After Michael's fix Nikos asked a question in the tracker.
>>> Maybe someone would like to address it. Please read below.
>>> 
>>>> Comment By: Nikos Alexandris (nikosa)
>>>> Date: 2007-11-30 01:50
>>>> 
>>>> Message:
>>>> I just tested and the "Max zoom in reached" message does the job  ;-)  --
>>>> Thank you!
>>>> 
>>>> Yet, I would like to share my skepsis about this:
>>>> 
>>>> a. "Maximum zoom-in reached." would be too long for a message (instead of
>>>> "Max")?
>> 
>> I'm not quite clear here. Do you want to use the word "maximum" instead of
>> "max"?
> 
> Yes.
>> 
>>>> b. Is it difficult to make it go back automatically to the last visible
>>>> zoom-in status instead of having to do it manually?
>> 
>> That's what it does on my system now. What does it do on your system?
> After I press ok it doesn't reload to the previous status. I need to
> either zoom-back or zoom to layer.


I just submitted this fix to the CVS yesterday or Thursday. Have you
updated?

Michael

> 
>> 
>>> 
>>> Maciek
>> 
>> __
>> Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


Re: [GRASS-dev] [grass-code I][544] Map Display crashes whenzooming (too much) in!

2007-12-01 Thread Michael Barton
I've changed the message box to say "Maximum zoom-in reached" and  
gotten rid of the redundant title that could not be read anyway.


Michael

On Dec 1, 2007, at 8:45 AM, Nikos Alexandris wrote:



On Sat, 2007-12-01 at 08:39 -0700, Michael Barton wrote:



On 12/1/07 4:12 AM, "Maciej Sieczka" <[EMAIL PROTECTED]> wrote:


After Michael's fix Nikos asked a question in the tracker.
Maybe someone would like to address it. Please read below.


Comment By: Nikos Alexandris (nikosa)
Date: 2007-11-30 01:50

Message:
I just tested and the "Max zoom in reached" message does the  
job  ;-)  --

Thank you!

Yet, I would like to share my skepsis about this:

a. "Maximum zoom-in reached." would be too long for a message  
(instead of

"Max")?


I'm not quite clear here. Do you want to use the word "maximum"  
instead of

"max"?


Yes.


b. Is it difficult to make it go back automatically to the last  
visible

zoom-in status instead of having to do it manually?


That's what it does on my system now. What does it do on your system?

After I press ok it doesn't reload to the previous status. I need to
either zoom-back or zoom to layer.





Maciek


__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



--
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



C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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


[GRASS-dev] question about potential enhancements to dbms

2007-12-01 Thread Michael Barton

Martin,

I've been trying out your updates to the dbms module and fixing  
little odds and end. This is a fantastic tool. The ability to  
highlight vector features is really nice. I had a couple ideas for  
enhancements but wanted to run them by you before doing anything,  
since I don't want to mess up any plans you already have.


1) What about adding a "display selection" button? Currently, you  
need to double click a record for it to highlight (AFAICT). This is  
easy for a single record, but trickier for multiple selections. A  
"display selection" button would make this easier. It could also make  
it easy to display the results of an SQL selection.


2) How about an "extract to new vector" button? This would take the  
current selection and run v.extract to create a new vector based on  
your sql or interactive selection.


Finally, I have a question (actually a group of questions). I can  
easily edit the first record in the browse list control, but can't  
edit any other ones. Is this a setting? A bug? Is a button needed to  
turn on editing? Could it be with double clicks if we have a display  
selection button?


Also, there is a bug in an editable list control that I've reported  
and I'm wondering if you have it with Linux too. I can edit any field  
that is showing completely in the window, without scrolling to the  
right. If you have to scroll right to the field, and double click to  
edit it, it will edit some field to the left instead of the field you  
intended to edit. It shows up for me in the wxPython demo as well as  
in the dbms table.


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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

[GRASS-dev] new screenshots of wxPython GUI

2007-12-01 Thread Michael Barton

Hamish,

I just posted a series of new screenshots for the new wxPython GUI to

<http://www.public.asu.edu/~cmbarton/files/grass_screenshots/ 
wxGUI_screenshots_2007-12-1.zip>


You might find a few worth putting in your new, nice screenshot pages.

Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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

Re: [GRASS-dev] [grass-code I][544] Map Display crashes whenzooming (too much) in!

2007-12-01 Thread Michael Barton
glad it is working now.

Always a good idea to do a make distclean before compiling, after updating.

Michael


On 12/1/07 8:07 PM, "Nikos Alexandris"
<[EMAIL PROTECTED]> wrote:

> Sorry for the traffic to all!
> 
> I just found out that the message "Maximum zoom-in reached" appears
> only  when I zoom in where two pixels meet eachother!
> 
> When I zoom in in one pixel no error message appears.
> 
> 
> On Sat, 2007-12-01 at 09:35 -0700, Michael Barton wrote:
>> I've changed the message box to say "Maximum zoom-in reached" and
>> gotten rid of the redundant title that could not be read anyway.
>> 
>> Michael
>> 
>> On Dec 1, 2007, at 8:45 AM, Nikos Alexandris wrote:
>> 
>>> 
>>> On Sat, 2007-12-01 at 08:39 -0700, Michael Barton wrote:
>>>> 
>>>> 
>>>> On 12/1/07 4:12 AM, "Maciej Sieczka" <[EMAIL PROTECTED]> wrote:
>>>> 
>>>>> After Michael's fix Nikos asked a question in the tracker.
>>>>> Maybe someone would like to address it. Please read below.
>>>>> 
>>>>>> Comment By: Nikos Alexandris (nikosa)
>>>>>> Date: 2007-11-30 01:50
>>>>>> 
>>>>>> Message:
>>>>>> I just tested and the "Max zoom in reached" message does the
>>>>>> job  ;-)  --
>>>>>> Thank you!
>>>>>> 
>>>>>> Yet, I would like to share my skepsis about this:
>>>>>> 
>>>>>> a. "Maximum zoom-in reached." would be too long for a message
>>>>>> (instead of
>>>>>> "Max")?
>>>> 
>>>> I'm not quite clear here. Do you want to use the word "maximum"
>>>> instead of
>>>> "max"?
>>> 
>>> Yes.
>>>> 
>>>>>> b. Is it difficult to make it go back automatically to the last
>>>>>> visible
>>>>>> zoom-in status instead of having to do it manually?
>>>> 
>>>> That's what it does on my system now. What does it do on your system?
>>> After I press ok it doesn't reload to the previous status. I need to
>>> either zoom-back or zoom to layer.
>>> 
>>>> 
>>>>> 
>>>>> Maciek
>>>> 
>>>> __
>>>> Michael Barton, Professor of Anthropology
>>>> Director of Graduate Studies
>>>> School of Human Evolution & Social Change
>>>> Center for Social Dynamics & Complexity
>>>> Arizona State University
>>>> 
>>>> phone: 480-965-6213
>>>> fax: 480-965-7671
>>>> www: http://www.public.asu.edu/~cmbarton
>>>> 
>>>> 
>>> -- 
>>> 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
>> 
>> 
>> C. Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> Phone: 480-965-6262
>> Fax: 480-965-7671
>> www: 
>> 
>> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] overzooming crash

2007-12-02 Thread Michael Barton

Maris,

It turned out that your issue was different from Niko's, though related.

I've set the display to reach the maximum zooming limit when it hits  
1x1 cell (i.e., the resolution set by g.region) rather than 1x1 map  
units (the way it was before). This fixes your problem too.


Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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

[GRASS-dev] Re: wingrass and nviz

2007-12-02 Thread Michael Barton

He can launch it both from the *.bat file AND from the mysys terminal.

Launched from the *.bat file, nviz doesn't work (at least it doesn't  
at present). It DOES work when GRASS is launched from the mysys  
terminal.


Michael

On Dec 3, 2007, at 12:26 AM, Moritz Lennert wrote:


Michael Barton wrote:
One of my RA's got nviz to work, after reading your posts about  
scripts. But it required putting the grass directory INSIDE of the  
mysys directory, since mysys seems to have trouble finding  
locations above the level of it root directory.

Have any of you found this?


Once again, could you please clarify how grass is launched exactly ?

If you work within the msys shell and launch grass from within  
msys, make sure you launch the grass63 script. This works just like  
in *nix and calls Init.sh which adds GISBASE to the PATH, so you  
should not have to move around anything.


Moritz


________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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


Re: (Fwd) [GRASS-dev] Change the resolution in the output map

2007-12-03 Thread Michael Barton
Juan,

Why don't you just use one of the several resampling methods built into
GRASS instead of writing something in C?

r.resample
r.resample.stats
r.resample.interp
r.resample.rst

Michael

On 12/3/07 3:13 AM, "Juan Diego Giraldo Osorio" <[EMAIL PROTECTED]>
wrote:

> 
> Hi coworkers
> 
> I have received an answer to my question from Glynn, but I erased it and
> I haven't realized. I ask send me the answer again please.
> 
> Thanks
> 
> Juan
> 
> --
> 
> Juan Diego Giraldo Osorio
> Tel. 968 327 047
> Departamento de Ingeniería Térmica y de Fluidos
> Universidad Politécnica de Cartagena
> España
> 
> 
> 
> -- Mensaje reenviado --
> Para: [EMAIL PROTECTED]
> Asunto: [GRASS-dev] Change the resolution in the output map
> De: "Juan Diego Giraldo Osorio"<[EMAIL PROTECTED]>
> Fecha: Fri, 30 Nov 2007 17:22:18 +0100 (CET)
> 
> Hi coworkers
> 
> I'm working with grass62. I'm triying to create a raster map with finer
> resolution from another with coarse resolution. The problem is the next:
> 
> - My coarse resolution map (input map) have 500 m of resolution, with
> 1000x1000 rows*cols. This information is the same as the current region.
> - I want to create a finer resolution map (output map) with 100 m of
> resolution, with 5000x5000 rows*cols.
> - I have been trying with the next code:
> 
> /* Adjust the region to new resolution */
> region.rows = nsubpixel*nrows;
> region.cols = nsubpixel*ncols;
> region.format = 0;
> region.compressed = 1;
> G_adjust_Cell_head( ®ion , 1 , 1 );
> G_set_window(®ion);
> 
>   nsubpixel is 5 (500/100), and I'm writing a new header file with this
> new information (region.rows=5000, region.cols=5000, region.ew_res=100,
> region.ns_res=100) but when I read the new map, the next message error
> is shows:
> 
>   WARNING: error reading null row 115
>   ... a lot of times.
> 
> Thanks for your help.
> 
> Juan Diego Giraldo
> --
> 
> Juan Diego Giraldo Osorio
> Tel. 968 327 047
> Departamento de Ingeniería Térmica y de Fluidos
> Universidad Politécnica de Cartagena
> España
> ********
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


[GRASS-dev] FW: [GRASS-user] GRASS for windows script solution

2007-12-03 Thread Michael Barton
Moritz,

Here is more information on GRASS for Windows and NVIZ from Isaac. We still
can¹t get NVIZ to launch if GRASS is started from the grass.bat file. Given
that it DOES work fine if launched from within MySys, it seems that this
must be some kind of path issue that is potentially solvable.

Also, I think we need to make MySys a dependency of GRASS for Windows. There
is just too much lost by not having access to the scripts‹including the nviz
script. Users without MySys will perceive GRASS as partly non-functional.
This is not a problem license-wise is it?

Michael
__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> -- Forwarded Message
> From: Isaac Ullah <[EMAIL PROTECTED]>
> Date: Mon, 3 Dec 2007 11:44:20 -0700
> To: Michael Barton <[EMAIL PROTECTED]>
> Subject: Re: FW: [GRASS-user] GRASS for windows script solution
> 

> I tried both of these solutions, and neither resulted in success (ie. NVIS
> still does not launch!) So far, the only solution that works for me is to move
> the grass install directory into the c:\mysys\1.0 directory, edit the
> "grass63" shell script so that the GISBASE is now set to
> "/c/msys/1.0/grass63RC2/grass- 6.3.0RC2", and then start grass by invoking
> that script at the command prompt in the mysys shell. If the grass directory
> is not installed in the mysys root directory, (ie. it's just in c:\) then
> mysys can find it since I can't cd in the mysys terminal below the mysys root
> folder "c/mysys/1.0/"
> 
> Cheers,
> 
> Isaac
> 
> On 11/29/07, Michael Barton <[EMAIL PROTECTED]> wrote:
>> Did you try the solution listed below?
>> 
>> Michael
>> __
>> Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics and Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> -- Forwarded Message
>>> > From: Moritz Lennert <[EMAIL PROTECTED]>
>>> > Date: Wed, 28 Nov 2007 11:38:31 +0100
>>> > To: francesco < [EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]> >
>>> > Cc: <[EMAIL PROTECTED]>
>>> > Subject: Re: [GRASS-user] GRASS for windows script solution
>>> >
>>> > On 28/11/07 11:01, francesco wrote:
>>>> >> Hello,
>>>> >>
>>>> >> For all fearless Wingrass users,  I would like to share a solution for
>>>> >> the following bug  "many shell scripts do not work, even if you
>>>> >> enable correctly msys and include LIB and BIN paths in the PATH windows
>>>> >> variable" (from the readme file at the wingrass webpage).
>>>> >>
>>>> >> PROBLEM - Long story short, g.mlist gave me errors because it did not
>>>> >> fine "sed" and other executables, therefore scripts like g.mlist and
>>>> >> g.mremove do not work
>>>> >> SOLUTION -
>>>> >>1 - open the "Init.bat" file located in the
>>>> >> "/grass-6.3.xxx/*etc*" ... do not use
>>>> >> notepad but a better editor that recognizes unix formatted text
>>>> >>2 - add the line below *after* the   ..if not
>>>> >> "%GRASS_ADDON_PATH%"==.. line (should be line 29)
>>>> >>   set PATH=/c/msys/1.0/bin;%PATH%
>>>> >>3 - of course /c/msys/1.0/bin is the path to the bin directory of
>>>> >> msys, if yours is different, adapt.
>>>> >>4 - start grass and try.
>>> >
>>> > As mentioned int he README: "in order for shell scripts to work, you
>>> > will have to add msys' lib and bin directories to your path in the
>>> > grass63.bat file."
>>> >
>>> > So, no need to fiddle with Init.bat, just add it in grass63.bat:
>>> >
>>> > set PATH=%PATH+;c:\msys\1.0\bin;c:\msys\1.0\lib
>>> >
>>> > The information used to be in the .bat file, but we decided to take it
>>> > out in the effort of making wingrass independent of msys. But seeing the
>>> > many reactions on this, I think I will add it again.
>>> >
>>> > Moritz
>>> >
>>> >
>> 
>> -- End of Forwarded Message
>> 
> 
> 
> 
> -- 
> 
> Isaac I Ullah, M.A.
> 
> Archaeology PhD Student,
> ASU School of Evolution and Social Change
> 
> Research Assistant,
> Mediterranean Landscape Dynamics Project
> ***
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> http://www.public.asu.edu/~iullah
> ***


-- End of Forwarded Message

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

Re: [GRASS-dev] location invalid if PERMANENT contains no WIND file ?

2007-12-07 Thread Michael Barton
I understand, but thought that the section where this is checked in init.sh
was still broken with regard to crashing on startup with incorrect or empty
GISDBASE, LOCATION, or MAPSET. If that part is already fixed, we only need
to fix the particular item you ran into.

Michael


On 12/7/07 4:24 PM, "Hamish" <[EMAIL PROTECTED]> wrote:

>> Michael Barton wrote:
>>> There is a larger issue that I think may still be unsolved (though
>>> Hamish's post makes me wonder now). In the past, if the .grassrc6 file
>>> pointed to an incorrect GISDBASE, LOCATION, or MAPSET value (i.e., one that
>>> did not exist), GRASS will automatically go into text mode and exit.
>>> 
>>> IMHO, it should simply bring up the startup screen for selecting the proper
>>> GISDBASE, LOCATION, and MAPSET. But it never got to the GUI.
> 
> Moritz Lennert wrote:
>> For me this is exactly what I get with CVS head: an error message and
>> when I click on ok I can chose the correct GISDBASE.
> 
> 
> I was referring to starting GRASS directly from the command line with the path
> to the mapset, not from the GUI.
> 
> 
> Hamish
> 
> 
> 
>   
> ______
> __
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


Re: [GRASS-dev] location invalid if PERMANENT contains no WIND file ?

2007-12-07 Thread Michael Barton
I agree. There is a larger issue that I think may still be unsolved (though
Hamish's post makes me wonder now). In the past, if the .grassrc6 file
pointed to an incorrect GISDBASE, LOCATION, or MAPSET value (i.e., one that
did not exist), GRASS will automatically go into text mode and exit.

IMHO, it should simply bring up the startup screen for selecting the proper
GISDBASE, LOCATION, and MAPSET. But it never got to the GUI.

Michael


On 12/7/07 8:53 AM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote:

> On 07/12/07 10:42, Glynn Clements wrote:
>> Moritz Lennert wrote:
>> 
>>> In gis_set.tcl there is a check for a valid location which reads:
>>> 
>>> # All good locations have valid PERMANENT mapset.
>>> if {[file exists "$dir/PERMANENT/WIND"] != 0} {
>>>set found 1
>>> 
>>> Shouldn't this check for DEFAULT_WIND instead of WIND ?
>> 
>> I can see some sense in that. The only time that PERMANENT/WIND will
>> actually be used is if PERMANENT is used as the current mapset, which
>> may never happen. OTOH, PERMANENT/DEFAULT_WIND must exist in order to
>> create new mapsets.
>> 
> 
> In this particular case, I could not enter the location via the GUI
> startup, but had no problem using it via the text startup.
> 
> There is the same kind of test for mapsets (lines 499ff and 650ff):
> 
>if {[file exists "$database/$location/$mapset/WIND"] == 0} {
>  DialogGen .wrnDlg [G_msg "WARNING: invalid mapset"]
> warning \
>  [format [G_msg "Warning: <%s> is not a valid
> mapset"] $mapset] \
>  0 OK;
>  }
> if { $mapset != "" && [file exists "$database/$location/$mapset/WIND"]
> != 0} {
>  puts stdout "GISDBASE='$database';"
>  puts stdout "LOCATION_NAME='$location';"
>  puts stdout "MAPSET='$mapset';"
>  putGRASSRC $gisrc_name
>  exit 0
>  }
>  }
> 
> 
> Again, should a missing WIND file be a reason to fail entering a mapset
> ? I think gis_set.tcl should just silently copy PERMANENT/DEFAULT_WIND
> to $mapset/WIND ?
> 
> Moritz
> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

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


Re: [GRASS-dev] location invalid if PERMANENT contains no WIND file ?

2007-12-08 Thread Michael Barton

This sounds like a good idea.

Michael

On Dec 8, 2007, at 10:00 AM, [EMAIL PROTECTED] wrote:


Send grass-dev mailing list submissions to
grass-dev@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/grass-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-dev digest..."
Today's Topics:

   1. Re: location invalid if PERMANENT contains no WIND file ?
  (Glynn Clements)

From: Glynn Clements <[EMAIL PROTECTED]>
Date: December 8, 2007 5:51:49 AM MST
To: Moritz Lennert <[EMAIL PROTECTED]>
Cc: grass-dev 
Subject: Re: [GRASS-dev] location invalid if PERMANENT contains no  
WIND file ?




Moritz Lennert wrote:


In gis_set.tcl there is a check for a valid location which reads:

# All good locations have valid PERMANENT mapset.
if {[file exists "$dir/PERMANENT/WIND"] != 0} {
   set found 1

Shouldn't this check for DEFAULT_WIND instead of WIND ?


I can see some sense in that. The only time that PERMANENT/WIND will
actually be used is if PERMANENT is used as the current mapset,  
which
may never happen. OTOH, PERMANENT/DEFAULT_WIND must exist in  
order to

create new mapsets.



In this particular case, I could not enter the location via the GUI
startup, but had no problem using it via the text startup.

There is the same kind of test for mapsets (lines 499ff and 650ff):

   if {[file exists "$database/$location/$mapset/ 
WIND"] == 0} {
 DialogGen .wrnDlg [G_msg "WARNING: invalid  
mapset"]

warning \
 [format [G_msg "Warning: <%s> is not a valid
mapset"] $mapset] \
 0 OK;
 }
if { $mapset != "" && [file exists "$database/$location/$mapset/ 
WIND"]

!= 0} {
 puts stdout "GISDBASE='$database';"
 puts stdout "LOCATION_NAME='$location';"
 puts stdout "MAPSET='$mapset';"
 putGRASSRC $gisrc_name
 exit 0
 }
 }

Again, should a missing WIND file be a reason to fail entering a  
mapset
? I think gis_set.tcl should just silently copy PERMANENT/ 
DEFAULT_WIND

to $mapset/WIND ?


AFAIK, the idea is to prevent the user from selecting some random
subdirectory of the location as the current mapset. This allows the
location directory to have subdirectories which aren't mapsets and
which won't be mistaken for mapsets.

The convention is that $dir is a valid location if $dir/PERMANENT/WIND
exists, and that $dir is a valid mapset if $dir/WIND exists.

The former could reasonably be changed to look for
$dir/PERMANENT/DEFAULT_WIND instead of $dir/PERMANENT/WIND. I don't
think that the latter should be changed.

--
Glynn Clements <[EMAIL PROTECTED]>



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



C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

[GRASS-dev] Some migration news

2007-12-10 Thread Michael Barton

Just a quick positive note.

I set up my subversion repository and did a successful checkout of  
the GRASS source (trunk) from the new repository. Works like a charm.  
I haven't tried to commit anything yet.


Michael

On Dec 10, 2007, at 10:00 AM, [EMAIL PROTECTED] wrote:


From: Markus Neteler <[EMAIL PROTECTED]>
Date: December 9, 2007 3:52:25 PM MST
To: GRASS developers list 
Subject: [GRASS-dev] Some migration news


Hi developers,

Martin has prepared the final SVN dump of the migrated CVS
repository with all tags brought into common form and
other nice fixes. The dump is currently transferred to
OSGeo and will be imported there later tonight.

Meanwhile Trac (which should serve us as developers platform
while the user Wiki remains Mediawiki) is getting populated:

# Main page:
http://trac.osgeo.org/grass/wiki

# Releases
http://trac.osgeo.org/grass/roadmap?show=all

# Tickets (have to be migrated from GForge and maybe also RT)
http://trac.osgeo.org/grass/report

More to come soon,
Markus


____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

[GRASS-dev] Question about SVN access via Trac

2007-12-11 Thread Michael Barton
The Trac page is nice. It's easy to quickly access the source code  
and bug tracker, and the view changes feature is especially helpful.  
One thing that seems missing is the ability to download a tarball of  
all or part of the source code. This was particularly handy to give  
non-developers easy access to code in GRASS addons. Is this something  
that can be added or was it specific to the SVN web access features  
of the old addons site?


Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

Re: [GRASS-dev] GRASS link on OSGeo subversion page?

2007-12-11 Thread Michael Barton
There it is now! Thanks.

Michael


On 12/11/07 7:57 AM, "Martin Landa" <[EMAIL PROTECTED]> wrote:

> Hi Michael,
> 
> 2007/12/11, Michael Barton <[EMAIL PROTECTED]>:
>>  Any reason that GRASS doesn't show up on the OSGeo WIKI subversion page?
>> 
>> <http://wiki.osgeo.org/index.php/Subversion>
> 
> fixed
> 
> Martin
> 
>> 
>> Michael
>> 
>> 
>> 
>> C. Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> Phone: 480-965-6262
>> Fax: 480-965-7671
>> www: 
>> 
>> 
>> 
>> _______
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
> 

__
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] GRASS link on OSGeo subversion page?

2007-12-11 Thread Michael Barton

Any reason that GRASS doesn't show up on the OSGeo WIKI subversion page?

<http://wiki.osgeo.org/index.php/Subversion>

Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

Re: [GRASS-dev] Question about SVN access via Trac

2007-12-11 Thread Michael Barton
I think the nightly tarballs would suffice. Can this be done for the  
Addons directories too?


Michael

On Dec 11, 2007, at 9:18 AM, Frank Warmerdam wrote:


Moritz Lennert wrote:


Michael,

A number of projects run cronjobs on download.osgeo.org to prepare  
night
SVN snapshots.  Would this satisfy the need you see?  I can work  
with anyone

interested in setting this up.
I think that a 'download tarball' button would be nice, as this  
allows to download a tarball of just any directory you want.

>
This seems to be implemented in Trac, but needs to be configured  
via the 'downloadable_paths' variable. See http://trac.edgewall.org/wiki/TracIni#svn 
.


Moritz,

I reviewed this and it appears this just gives the one-file-at-a-time
downloading option.  It does not appear to allow downloading  
directories

and directory trees as a tarball.

But it's obviously also a question of resource usage this might  
imply for the osgeo server.


We do disallow robots into many parts of Trac to avoid big downloads.
We used to have a lot of problems with google and other robots  
requesting

huge version diffs (ie. between r1 and r2 on /trunk!) during their
scans.  In many cases this produced multi-gigabyte diffs and would  
crash

the main server.

Beyond that it isn't such an issue.  But given that Trac does not seem
to provide the desired service, I think we are back to preparing
nightly tarballs.

Best regards,
--
--- 
+--

I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| President OSGeo, http://osgeo.org



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


Re: [GRASS-dev] Question about SVN access via Trac

2007-12-11 Thread Michael Barton

Thanks Frank. This sounds very flexible.

Michael
__
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Dec 11, 2007, at 10:01 AM, Frank Warmerdam wrote:


Michael Barton wrote:
I think the nightly tarballs would suffice. Can this be done for  
the Addons directories too?



Michael,

It can be pretty much whatever you want.   I am attaching two scripts
I use for gdal.  One, mkgdaldist.sh prepares a source distribution  
from
subversion.  The other, gdalnightlysvn.sh, uses mkgdaldist.sh to  
create
trunk and stable branch snapshots and rotates them into the OSGeo  
download

directory for gdal nightly snapshots.

Basically, if the GRASS project can provide a script or scripts that
does this rough task, I'm prepared to setup a cronjob, or better yet
whoever on the GRASS project that has a userid on download.osgeo.org
could set it up, perhaps asking me questions.

Best regards,
--
--- 
+--

I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| President OSGeo, http://osgeo.org




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


RE: [GRASS-dev] slow access to osgeo svn

2007-12-15 Thread Michael Barton
I second that. Overall, my university is relatively decent on this  
(Skype, iChat, and other services are available). But IRC is blocked  
and I cannot use it from there.


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 15, 2007, at 10:00 AM, [EMAIL PROTECTED] wrote:


From: "Patton, Eric" <[EMAIL PROTECTED]>
Date: December 14, 2007 3:03:46 PM MST
To: "Markus Neteler" <[EMAIL PROTECTED]>, 
Subject: RE: [GRASS-dev] slow access to osgeo svn


You can easily reach IRC with zero installation through this Web  
client:


http://irc.telascience.org/cgi-bin/irc.cgi
- select reasonable nick name
- select #osgeo



Then they can check immediately what's going on.



Markus


A lot of irc protocols are blocked or forbidden behind corporate/ 
government firewalls for some of us (big brother is always  
watching), so that isn't always an option.


~ Eric.


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

Re: [GRASS-dev] IRC over HTTP :: slow access to osgeo svn

2007-12-15 Thread Michael Barton

Thanks for the information Hamish. I'll give it a try.

Michael
____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 15, 2007, at 4:16 PM, Hamish wrote:


Markus wrote:

You can easily reach IRC with zero installation through this Web
client:

http://irc.telascience.org/cgi-bin/irc.cgi
- select reasonable nick name
- select #osgeo

Then they can check immediately what's going on.


Eric:

A lot of irc protocols are blocked or forbidden behind corporate/
government firewalls for some of us (big brother is always
watching), so that isn't always an option.


Michael:

I second that. Overall, my university is relatively decent on this
(Skype, iChat, and other services are available). But IRC is blocked
and I cannot use it from there.



the whole point of  http://irc.telascience.org/cgi-bin/irc.cgi  is  
that

you interface with the IRC channel over a web page, not using the IRC
protocol. Therefore if the IRC protocol/port is blocked by your  
service

provider you can still connect through the above webpage bypassing the
block. IRC's file transfer functions etc don't work over that AFAIK so
I think the web interface is not prone to the type of abuse that a  
non-

authoritarian IT dept would be worried about.

Now if the "forbidden" policy is written as the activity not as the
protocol/port, well then you take your chances of getting caught doing
something naughty.

Otherwise try it, as long as you can access web pages it'll probably
work.


Hamish



   
__ 
__

Looking for last minute shopping deals?
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/ 
newsearch/category.php?category=shopping




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


[GRASS-dev] error saving tifs from NVIZ in winGRASS

2007-12-19 Thread Michael Barton

Moritz,

Further testing grass has revealed an odd problem. It claims that  
there is no tif support. However, we CAN make tifs using r.out.gdal  
(even though not all Windows apps like them).


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Begin forwarded message:


From: "Sean Bergin" <[EMAIL PROTECTED]>
Date: December 19, 2007 1:59:56 PM GMT-07:00
To: "Michael Barton" <[EMAIL PROTECTED]>
Subject: tif error message
Reply-To: [EMAIL PROTECTED]

Error: no TIFF support
Error: no TIFF support
while executing
"Nwrite_tif $fname"
(procedure "dump_tif" line 12)
invoked from within
"dump_tif"
(menu invoke)

--
Sean Bergin
Ph.D. Student, Archaeology
Graduate Assistant, Integrating Socio-Ecological Sciences Project
School of Human Evolution and Social Change, ASU
Tempe, AZ 85287-2402

[EMAIL PROTECTED]


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

[GRASS-dev] Fix NVIZ before the 6.3.0 release

2007-12-20 Thread Michael Barton
I just learned that the position function in NVIZ is broken. There is  
some problem with a TclTk panel name reference. Probably easy to fix  
if it can be found.


I'll try if I have time, but the next couple weeks will be really  
busy. So if anyone else is game to try...


Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

[GRASS-dev] Re: vector works in X0 monitor but not in gis.m (Daniel Victoria)

2007-12-27 Thread Michael Barton
I've committed the fix below suggested by Glynn. I tested it on the  
new NC demo data set and it causes no problems.


Of course, the old regexp statement worked too in my tests. Since I'm  
so abysmal at regexp, I just have to go with this, like I did with  
the old statement (someone else suggested it to fix an earlier  
problem with latlon regions).


Could someone please test this since I'm not completely clear what  
breaks the old algorithm that works with this one? Hopefully this  
will work with all projections this time.


Michael
________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 27, 2007, at 6:38 AM, [EMAIL PROTECTED] wrote:



Probably related to this in mapcanvas.tcl:

# Finally put this into wind file format to use  
with GRASS_REGION
regexp -nocase {^.* (\(.*\))} $parts(projection)  
trash end
set parts(projection) [string trim $parts 
(projection) $end]



The "*" operator will try to match as much as possble, so matching  
the

string "99 (Polyconic (American))" against the regexp"^.* (\(.*\))"
will result in the ".*" matching ""99 (Polyconic " and the "(\(.*\))"
matching "(American))", so "end" will be set to "American)"

Also, using "string trim" here is bogus; it discards any leading or
trailing section consisting of characters in the specified string,
which may be more than just the string itself (if $end contains the
digit 9, it will strip the projection code).

It should probably just match the portion that it wants, e.g.:

regexp -nocase {^([0-9]+)} $parts(projection) trash parts 
(projection)


rather than trying to match and discard the portion that it doesn't
want.



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

Re: [GRASS-dev] C replacement for d.vect.thematic

2007-12-29 Thread Michael Barton

Moritz,

I'm really excited about this. Thanks so much for the efforts. I'll  
certainly try it out if I can (intensive proposal writing for the  
next week). In the meantime, here are a few comments based on your  
email and the html docs.


I agree with the idea of chaining smaller modules. d.vect.thematic is  
really complicated and bloated by having to include all the  
functionality into a single module.


v.class is similar to r.stats in what it does. You might want to  
consider naming it v.stats to make it easier for users to grok this  
similarity. I assume that v.class will also output to a text file?


I'd rename the thematic modules to d.thematic.area, d.thematic.point,  
d.thematic.legend. This lets them easily group in any alphabetical  
listing and clearly associates them. It also uses consistent GIS  
objects for the subname of each (i.e., point instead of symbol,  
because points and areas are the objects being displayed).


What about lines? Can v.class classify lines and boundaries, and  
d.area.thematic  display them by color and thickness? Or will that  
need another module?


Finally, is there any way to make use of color table capabilities,  
like used with r.colors? This would allow a lot of nice displays more  
easily than having to list colors.


Thanks again for doing this.

Michael



Can we make use of the kind of color tables used by r.colors to get  
color ramps in d.area.thematic?


On Dec 29, 2007, at 10:00 AM, [EMAIL PROTECTED] wrote:



From: Moritz Lennert <[EMAIL PROTECTED]>
Date: December 29, 2007 9:22:44 AM MST
To: GRASS devel 
Subject: [GRASS-dev] C replacement for d.vect.thematic


Hello everyone,

I have finally started living up to my many promises over the last  
year about trying to write a C replacement for the d.vect.thematic  
script.


I have decided to split the script up into several modules as I  
think d.vect.thematic is a bit overloaded. In the end I would like  
to come up with something like:


- library functions for classification of vector attribute data  
using different algorithms

- v.class: a module for classifying vector attribute data
- d.area.thematic: a module for choropleth area maps
- d.symbol.thematic: a module for line and point symbol thematic  
mapping, including symbol size variation
- d.thematic.legend: a module which takes the output of the other  
two d.* modules and draws a nice legend



At this stage I have the two first modules in a usable state, i.e.  
v.class and d.area.thematic. For those interested, they are  
available at [1]. I deliberately kept d.area.thematic very simple,  
forcing the user to enter class breaks and colors, but you can use  
v.class -g to create the class breaks for d.area.thematic (see  
example in description.html). In my eyes it is better (and more in  
the spirit of GRASS) to create a toolchain of small modules which  
can feed into each other. It should be no problem combining them in  
a gui or a script.


I still need to enhance documentation (of the module and of the  
functions).


At this stage I have all the classification functions in a file  
with v.class, but I think it would be good to move them to a  
library pretty soon so that they can be shared by modules.


But before I go on (which in any case probably won't happen within  
the next week), I have a few questions:


- Any fundamental disagreement with the general scheme (i.e.  
several separate modules) ?
- I guess I should create a new library with vector stats  
functions, which could then hold the classification functions, but  
also the (currently named) dbCatValArray_stats function for basic  
stats. The latter (+ extensions) could then also be used for e.g.  
v.univar. Any suggestions as to where to put the library (lib/ or  
lib/vect) ? If in lib, I suggest calling it libgrass_vstats as a  
counterpart to the raster libgrass_stats. Any opposition ?
- Could someone look over the code to see if I have not done  
anything bad ? The class_discont function in v.class/class.c is  
extremely difficult to read and could do with some better variable  
naming and probably refactoring. It is actually a direct  
translation of some 15-20 year old fortran code that we use  
inhouse, but as it works as it is, I'm not sure I want to spend  
much time on that now.


As soon as I either get answers or just impatient, I'll upload the  
code to svn, so that others can start hacking on it.


Moritz

[1] http://geog-pc40.ulb.ac.be/grass/thematic/





____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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

[GRASS-dev] Re: wxgrass Location Wizard scroll issue in EPSG code selection

2007-12-30 Thread Michael Barton
Thanks for testing this and the suggestions. I'm having to write on  
grant proposals over the next week and classes start right  
afterwards. But I'll try to steal some time to look into this. Are  
all three of these issues related to the EPSG page?


Michael
____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 30, 2007, at 6:26 AM, [EMAIL PROTECTED] wrote:




- either sort numerically by code (currently it seems to be string  
sorted)

- and/or enable sort-by-column through clicking on the column name

thanks
markus

On Dec 29, 2007 9:01 PM, Markus Neteler <[EMAIL PROTECTED]> wrote:

Hi,

[have added a makefile to gui/wxpython/ to have it automatically
installed if Python available]

I am testing the nice location wizard. There is a scroll issue
when searching in the EPSG DB for codes:

- "Search in code description":
   enter "UTM"

The list lacks a scroll bar... (in essence two scroll bars: one  
for x,
one for y direction). Since I cannot resize the location wizard  
window,

I cannot really navigate there.

Could this be fixed?

thanks
Markus





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

Re: [GRASS-dev] C replacement for d.vect.thematic

2007-12-31 Thread Michael Barton

Thanks for the replies Moritz,

A couple responses.

On Dec 31, 2007, at 2:45 AM, Moritz Lennert wrote:


On 29/12/07 18:25, Michael Barton wrote:
v.class is similar to r.stats in what it does. You might want to  
consider naming it v.stats to make it easier for users to grok  
this similarity. I assume that v.class will also output to a text  
file?


It prints to standard output so you can redirect to a text file.  
But I'm not sure I see how it is so similar to r.stats... Will  
think about it.


Unless there is an explicit text out option, you cannot send to a  
file from the GUI. Can you add this?


Regarding r.stats, I guess I was thinking that it can give you cell  
counts according to a number of predefined user 'breaks'. Thinking  
more, it could certainly be nice if there was a raster module that  
did the same kind of classification as you've done here with vectors.  
So, reconsidering, I agree with the name v.class...and now wish for  
an r.class too.




I'm actually also thinking about modifying the function to take  
arbitrary float vectors, and not dbCatValArrays, thus allowing the  
classification of any data, not only vector, and also avoiding to  
carry around a whole dbCatValArray structure where only the actual  
values are needed.


Does this raise the possibility of an r.class?

What about lines? Can v.class classify lines and boundaries, and  
d.area.thematic  display them by color and thickness? Or will that  
need another module?


For me lines and points are symbols and I put them together into  
d.symbol.thematic, but I guess we should split them.


I see no problem combining these, especially since both rely on  
varying size and color. I could also see putting the line functions  
in with areas so that area boundaries could be visually classified.  
Or doing lines as a separate module. But if combined, the name should  
probably reflect such combinations (e.g., d.thematic.ptln or some  
such thing).




Finally, is there any way to make use of color table capabilities,  
like used with r.colors? This would allow a lot of nice displays  
more easily than having to list colors.


This would be great. I have also been thinking about a way to  
integrate the ColorBrewer palettes. Don't know their exact  
licensing, but I think uDig has integrated them, so should be  
possible. This could then lead to a g.colorbrewer which allows you  
to chose a palette according to different criteria and then output  
it for d.thematic or other modules.


I think it would also be great to have a GUI colorchooser module,  
but I think this will have to be a GUI element as IIUC g.parser  
does not allow for color buttons to change according to the color  
you chose and thus you cannot see all the colors you chose side by  
side (one of the most annoying things in QGIS IMHO).


If d.thematic.* modules could use the color table approach, a GUI  
could indeed be created for visual color picking. Take a look at the  
GUI for d.vect.thematic in the TclTk GIS manager. In fact, the  
wxPython version of automatic GUI dialog builder for GRASS commands  
(menuform.py) currently creates a colored button that launches a  
visual color picker for fields that take a color value.


I consider the current GUI for color rules in the TclTk and wxPython  
GUIs as only a stop-gap. Ultimately, I'd like to have a GUI for color  
table creation sort of along the lines of the one for point  
classification in NVIZ.



So, yes, lot's left to do...


But this is a really great start. Thanks!

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

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


[GRASS-dev] Re: [GRASS-user] Re: vector works in X0 monitor but not in gis.m (Daniel Victoria)

2007-12-31 Thread Michael Barton

Glad to hear it. Thanks to Glynn for the suggested fix.

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 31, 2007, at 9:47 AM, Daniel Victoria wrote:


Michael et al,

I'm happy to inform that I just compiled Grass from the latest svn and
the problem is gone. Map canvas works with both Polyconic American
projection and lat Long projection...

Cheers and happy new year!
Daniel

On Dec 27, 2007 7:07 PM, Daniel Victoria  
<[EMAIL PROTECTED]> wrote:

Thanks! I will gladly test the fix as soon as my r.watershed process
finishes. It's been running for 1 day and will probably take 2  
more to

end... my laptop is almost melting...

Thanks again
Daniel


On Dec 27, 2007 6:47 PM, Michael Barton <[EMAIL PROTECTED]>  
wrote:
 I've committed the fix below suggested by Glynn. I tested it on  
the new NC

demo data set and it causes no problems.

Of course, the old regexp statement worked too in my tests. Since  
I'm so
abysmal at regexp, I just have to go with this, like I did with  
the old
statement (someone else suggested it to fix an earlier problem  
with latlon

regions).

Could someone please test this since I'm not completely clear  
what breaks
the old algorithm that works with this one? Hopefully this will  
work with

all projections this time.

Michael


C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Dec 27, 2007, at 6:38 AM, [EMAIL PROTECTED]  
wrote:







Probably related to this in mapcanvas.tcl:




# Finally put this into wind file format to use with
GRASS_REGION

regexp -nocase {^.* (\(.*\))} $parts(projection)  
trash end


set parts(projection) [string trim $parts 
(projection) $end]








The "*" operator will try to match as much as possble, so  
matching the


string "99 (Polyconic (American))" against the regexp"^.* (\(.*\))"

will result in the ".*" matching ""99 (Polyconic " and the "(\(.* 
\))"


matching "(American))", so "end" will be set to "American)"




Also, using "string trim" here is bogus; it discards any leading or

trailing section consisting of characters in the specified string,

which may be more than just the string itself (if $end contains the

digit 9, it will strip the projection code).




It should probably just match the portion that it wants, e.g.:




regexp -nocase {^([0-9]+)} $parts(projection) trash
parts(projection)




rather than trying to match and discard the portion that it doesn't

want.




___
grass-user mailing list
[EMAIL PROTECTED]
http://lists.osgeo.org/mailman/listinfo/grass-user






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


[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 1

2008-01-01 Thread Michael Barton


On Jan 1, 2008, at 3:13 AM, [EMAIL PROTECTED] wrote:



#12: gis.m->Help->About system doesn't work (launches another  
gis.m instance)
-- 
+-

  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  unspecified
Resolution:   |Keywords:
-- 
+-

Comment (by cmbarton):

 Replying to [ticket:12 neteler]:
Clicking on 'About System' within the gis.m Help menu launches a  
new set

 of gis.m windows instead of opening a tcl/tk window with system
 parameters. The newly created gis manager toolbar says "Tk System
 Information".


PS: moved here from
 http://wald.intevation.org/tracker/? 
func=detail&atid=204&aid=553&group_id=21


 Is this function worth the trouble of trying to fix?


This is just a symptom of a larger problem, namely that the Gm::errmsg
procedure is defined in gm.tcl, which cannot be "source"d (because
doing so will "run" gis.m).

Gm::errmsg belongs in a "library", i.e. a Tcl source file which can be
"source"d from other Tcl source files.

Also: gm.tcl calls Gm::errmsg from top-level code at the beginning of
the file (the code which copies various g.gisenv settings into $env),
although the procedure isn't actually defined until much later in the
file. If any of those "catch" statements actually catch an error, the
handler will throw an error due to Gm::errmsg being undefined.


Making a library and moving Gm::errmsg to it is pretty easy to fix  
(just a LOT of find/replace throughout the GUI code). Anything else  
that you know of should come out of gm.tcl and into such a library?


However, making the 'get system info' function work is more trouble.  
As I said in the rest of the post, it's very old code. Is it worth  
bothering with to have the GUI launch a window with a bit of minimal  
system info?


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

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

Re: [GRASS-dev] Re: #12: gis.m->Help->About system doesn't work

2008-01-02 Thread Michael Barton
Sounds like we don't really need this then. Anyone object to me  
getting rid of this menu entry?


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 1, 2008, at 2:14 PM, Hamish wrote:


#12: gis.m->Help->About system doesn't work (launches another
gis.m instance)
+---------


Michael Barton wrote:

As I said in the rest of the post, it's very old code. Is it worth
bothering with to have the GUI launch a window with a bit of minimal
system info?


Its primary use, AFAICT, is to help give the GUI devels extra info to
go along with user supplied debugging reports.


Hamish



  


Looking for last minute shopping deals?
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping



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


[GRASS-dev] Re: test of v.area.thematic

2008-01-02 Thread Michael Barton


On Jan 2, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Michael,

On 29/12/07 20:20, Michael Barton wrote:

Moritz,

Couldn't help myself and tried out the new v.area.thematic.

I very much like it, but there is something not working about the  
color
assignments. I tried the following, using the new NC GRASS demo  
data set.


GRASS 6.3.svn (nc_spm_07):~ > d.area.thematic map=censusblk_swwake
data=total_pop breaks='v.class map=censusblk_swwake column=total_pop
algo=std nbcla=4' colors=0:0:255,0:0:100,100:0:0,255:0:0 layer=1
bwidth=0 bcolor=yellow render=l



Two things are not correct in this command line:

- You need to use back ticks (`) and not single quotes (') aroung the
v.class command line.
- The example in the description.html was wrong: it should be  
v.class -g
so that you do not get the full v.class output, but only the shell  
style.


This should work:

d.area.thematic map=censusblk_swwake data=total_pop breaks=`v.class -g
map=censusblk_swwake column=total_pop algo=std nbcla=4`
colors=0:0:255,0:0:100,100:0:0,255:0:0 layer=1 bwidth=0 bcolor=yellow
render=l


Thanks Moritz. I'll try this when I get to my other computer.

Why are you using backquotes here? This seems non-standard with  
respect to other GRASS commands. Any idea if this works better (or  
worse) on Windows and in a GUI setting?


Michael

__________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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


[GRASS-dev] RE: [grass-doc I][574] v.in.ogr

2008-01-08 Thread Michael Barton


On Jan 7, 2008, at 11:20 PM, [EMAIL PROTECTED] wrote:



IIRC it is optional because you might want to just list the available
layers in the input OGR source (-l flag), in which case you don't  
need to

specify an output map.

Paul


I think it is also optional because by default v.in.ogr will use the  
name of the source file for the destination. I think that r.in.gdal  
does too.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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


[GRASS-dev] batch search and replace from command line?

2008-01-08 Thread Michael Barton
I'm betting there is a Unix command to do a batch search and replace  
of one string with another in all text files in a directory.


But I don't know what it is.

I'm trying to follow Glynn's advice to create a library of common  
TclTk procedures that can be called without calling another instance  
of gm.tcl (i.e., without launching another GIS Manager window).


These procedures (e.g., Gm::errmsg) get called a LOT in many modules.  
I'd like a way of replacing every occurance of "Gm::errmsg" with  
"GmLib::errmsg" in all modules in the TclTk GUI directory.


Can someone tell me if this is possible and, if so, how to do it?

Thanks
Michael


C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

Re: [GRASS-dev] batch search and replace from command line?

2008-01-09 Thread Michael Barton
I'm baffled by Benjamin's error. Did someone else create a gmlib.tcl  
module? I've been busy on grants and only started to work with it  
last night. I haven't committed anything.


Michael
________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 9, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Message: 1
Date: Wed, 09 Jan 2008 15:19:16 +0100
From: Benjamin Ducke <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] batch search and replace from command line?
To: GRASS devel <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Works fine again.
Cheers for the quick fixing.

Benjamin

Markus Neteler wrote:

Sorry, fixed in SVN.

Markus

On Jan 9, 2008 2:51 PM, Benjamin Ducke <[EMAIL PROTECTED] 
kiel.de> wrote:

With a fresh checkout from SVN (done about 3 hours ago),
I now get:

Error in startup script: can't create procedure "GmLib::errmsg":  
unknown

namespace
while executing
"proc GmLib::errmsg { error args } {
# send error report and optional message (args) to tk_messageBox

set message ""

if { $args !..."
(file "/usr/local/grass-6.3.svn/etc/gm/gm.tcl" line 543)

when trying to launch gis.m

Best,

Benjamin



Markus Neteler wrote:

Done and submitted:
  http://trac.osgeo.org/grass/changeset/29624

I have used attached script.

Cheers
Markus


On Jan 9, 2008 7:02 AM, Michael Barton <[EMAIL PROTECTED]>  
wrote:
I'm betting there is a Unix command to do a batch search and  
replace of one

string with another in all text files in a directory.

But I don't know what it is.

I'm trying to follow Glynn's advice to create a library of  
common TclTk
procedures that can be called without calling another instance  
of gm.tcl

(i.e., without launching another GIS Manager window).

These procedures (e.g., Gm::errmsg) get called a LOT in many  
modules. I'd
like a way of replacing every occurance of "Gm::errmsg" with  
"GmLib::errmsg"

in all modules in the TclTk GUI directory.

Can someone tell me if this is possible and, if so, how to do it?

Thanks
Michael

-- 
--


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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

___
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] batch search and replace from command line?

2008-01-09 Thread Michael Barton
Thanks William. I use TextWrangler but didn't know it had this  
capability. This will be simple.


Michael
____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 9, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Message: 3
Date: Wed, 9 Jan 2008 09:03:09 -0600
From: William Kyngesburye <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] batch search and replace from command line?
To: Michael Barton <[EMAIL PROTECTED]>
Cc: GRASS developers list 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Looks like you got some response already, but on the GUI side on OSX,
BBEdit's find and replace can search whole folders of files.  Their
free TextWrangler also can.  Full GREP support in both, and you can
filter files.



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


[GRASS-dev] new procedures library for TclTk GUI

2008-01-09 Thread Michael Barton
Since a bunch of modules were inadvertently changed in the svn to use  
a (non-existent) procedures library, I've gone ahead and created this  
library. It has a common error procedure, a procedure for open and  
save file dialogs, rgb to hex color translation, and vector element  
type. All relevant modules have been updated to use this library.


Ironically, the issue that prompted this change--trying to launch  
Help System and getting multiple instances of the GIS Manager--is  
still a problem. Because there is some ambiguity over whether this is  
or is not useful, I'll leave it in the menu and look into it further  
when I have a chance.


Michael

____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

[GRASS-dev] Help > About System fixed

2008-01-09 Thread Michael Barton

I don't know why I didn't see this before.

It turned out to be simple to fix the problem with the Help > About  
System module. Someone had added a line ...


source $env(GISBASE)/etc/gm/gm.tcl

This line launched the GIS Manager every time About System was run.

I've deleted that line and it seems to work fine now.

Michael

________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 24

2008-01-11 Thread Michael Barton


On Jan 11, 2008, at 1:23 PM, [EMAIL PROTECTED] wrote:


Message: 7
Date: Sat, 12 Jan 2008 02:23:16 +0600
From: Ivan Shmakov <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] sqlite and grass64
To: grass-dev@lists.osgeo.org
Cc: Ivan Shmakov <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii


Michael Barton <[EMAIL PROTECTED]> writes:


[...]


AFAICT, SQLite has considerably more functionality than our current
dbf driver. I like it for a lot of reasons. A couple issues to
consider, however.



dbf is a widely recognized file format that can be read or imported
by very many other applications directly. While the SQLite database
engine can export into several interchange format, the native SQLite
file format is much less widely read by other applications.



Related to this, GRASS is very weak in interactive data management
capabilities. This constantly comes up when I demo GRASS. A saving
grace in this situation is the portability of the dbf attribute table
format. I can tell people that they can easily manage the attribute
tables in OpenOffice, for example. This is not the case with SQLite.


Not for the general side of the problem, but Google shows quite
a few links when queried for ``sqlite openoffice''.

[...]


I followed those out recently and found that 1) OO has an SQLite  
driver that is under development but not ready and perhaps not active  
development; 2) currently, the only way to access SQLite via OO is via  
ODBC. This requires commercial drivers on the Mac and possibly Windows.


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


Re: [GRASS-dev] sqlite and grass64

2008-01-11 Thread Michael Barton


On Jan 11, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Fri, 11 Jan 2008 15:20:37 +0100
From: "Markus Neteler" <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] sqlite and grass64
To: "Martin Landa" <[EMAIL PROTECTED]>
Cc: GRASS developers list <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

On Jan 11, 2008 2:26 PM, Martin Landa <[EMAIL PROTECTED]> wrote:

Hi devs,

I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?


Yes, that would be very good. AFAIK:

Functionality
- it does all the DBF driver does and way more

Portability
- works on all common operating systems

Installation efforts:
- despite the base installation, zero maintenance

Markus


AFAICT, SQLite has considerably more functionality than our current  
dbf driver. I like it for a lot of reasons. A couple issues to  
consider, however.


dbf is a widely recognized file format that can be read or imported by  
very many other applications directly. While the SQLite database  
engine can export into several interchange format, the native SQLite  
file format is much less widely read by other applications.


Related to this, GRASS is very weak in interactive data management  
capabilities. This constantly comes up when I demo GRASS. A saving  
grace in this situation is the portability of the dbf attribute table  
format. I can tell people that they can easily manage the attribute  
tables in OpenOffice, for example. This is not the case with SQLite.


Martin Landa is crafting a very nice interactive data manager for the  
wxPython GUI. When fully implemented, this will make the 2nd issue  
much less important. But this is not the default GUI yet. It would  
also be nice to be able to export an SQLite table to dbf format   
(along with delimited text formats supported) from within GRASS to  
deal with the 1st issue.


Michael

__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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


[GRASS-dev] Re: Python GUI requirements

2008-01-13 Thread Michael Barton

Which REQUIREMENTS.html document are you referring to?

For the wxPython GUI, you need Python 2.4 or greater and wxPython 2.8  
or higher (maybe 2.8.1, but you might need to ask Martin on that).


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 13, 2008, at 11:13 AM, William Kyngesburye wrote:

REQUIREMENTS.html mentions Python for the GUI, but a couple things  
are missing:


Is there a minimum version requirement?

It doesn't have wxPython as a requirement.

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

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?


[Marvin]  You think you have problems?  What are you supposed to do  
if you ARE a maniacally depressed robot?  No, don't try and answer,  
I'm 50,000 times more intelligent than you and even I don't know  
the answer...


- HitchHiker's Guide to the Galaxy




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


Re: [GRASS-dev] sqlite and grass64

2008-01-13 Thread Michael Barton



On Jan 13, 2008, at 4:40 PM, Glynn Clements wrote:



AFAICT, SQLite has considerably more functionality than our current
dbf driver. I like it for a lot of reasons. A couple issues to
consider, however.

dbf is a widely recognized file format that can be read or  
imported by

very many other applications directly. While the SQLite database
engine can export into several interchange format, the native SQLite
file format is much less widely read by other applications.


I would have expected most applications to access databases via ODBC,
rather than trying to interface with DBMS-specific libraries,
protocols or file formats directly.



Most desktop applications don't access databases via ODBC. Folks that  
ommonly use large databases--and especially remote ones--will likely  
be using ODBC on a regular basis. However, this is not the case for  
many (perhaps most) users. They will have small to modest sized local  
databases. Setting up ODBC is an extra step that will be complicated  
and confusing for people who are not familiar with it, even via  
GUI's. It shouldn't be necessary to simply access a small attribute  
table of GRASS vector data. I don't particularly like dbf, but it IS  
easily accessible from many apps.


SQLite Browser is a light-weight application that we could package  
with GRASS if we wanted to switch to SQLite before making wxPython  
the default GUI. It's nice, but my concern with it is that is appears  
not to have been updated for a couple years. I found one other free  
tool for the Mac to access SQLite databases (a couple others to  
manage them only). There seems to be more available for Windows and  
Linux.


Michael
________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

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


[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 30

2008-01-13 Thread Michael Barton


On Jan 13, 2008, at 3:06 PM, [EMAIL PROTECTED] wrote:


Date: Sun, 13 Jan 2008 22:35:24 +0100
From: "Martin Landa" <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] Python GUI requirements
To: "William Kyngesburye" <[EMAIL PROTECTED]>
Cc: Maris Nartiss <[EMAIL PROTECTED]>,GRASS developers list

Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2008/1/13, William Kyngesburye <[EMAIL PROTECTED]>:
 From what I could figure out about configure and make for GRASS  
Python:


--with-python enables wxpython.  See gui/Makefile.

The swig bindings are manually built -- see the note in swig/
makefile.  And they don't appear to have any connection with --with-
python.


I added --with-wxpython option to configure script. wxPython requires
--with-python, also checks for python version >= 2.4 and wxpython >=
2.8.

Martin


On Jan 13, 2008, at 1:09 PM, Maris Nartiss wrote:


Hi,
current trunk ./configure --help says that --with-python will enable
Python support (Python bindings?). Still I don't see any switch to
enable/disable wxpython. Shouldn't there be one?


Maris.


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

"Those people who most want to rule people are, ipso-facto, those
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


Currently, the wxPython GUI needs a separate installation of Python  
and wxPython. I don't think the Python SWIG interface makes any  
difference to the GUI (or does it do something with the digitizing  
module?). So what does this switch do?


Ultimately, I suppose we'll move to building this with runtime/ 
compiled versions so that users of prebuilt binaries don't have to  
install Python and wxPython. In the meantime, I don't understand the  
point of the switch.


Michael

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


[GRASS-dev] Re: [GRASS-user] Unable to create new project with Grass

2008-01-14 Thread Michael Barton
First, try an already created location. Put the location of one of  
the demo data sets into your grass data directory and try to see it.  
Once you can see it OK, quit GRASS (GUI and typing exit from the  
command line), restart GRASS, and try to create a mapset in the demo  
location. If that works, quit GRASS, restart GRASS, and try creating  
a dummy location using EPSG code.


Sorry for the complications, but this can help troubleshoot the problem.

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 14, 2008, at 2:04 AM, Jan Schorn wrote:


Michael Barton escribió:



On Jan 13, 2008, at 5:06 AM, [EMAIL PROTECTED]  
wrote:



Date: Sat, 12 Jan 2008 21:26:05 +
From: "Jan Schorn" <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] Unable to create new project with Grass
6.2.2 inUbuntu 7.1
To: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Hi, list
I installed GRASS 6.2.3 in about 14 computers with i368  
architecture and
Ubuntu 7.10 (Les-ejk repositorios). The only way to create a new  
Location is

using QGIS.
Using GRASS the error explained by Matt occurs.
¿Any ideas?

Thanks,
Jan


2008/1/11, Matt <[EMAIL PROTECTED]>:


I am unable to create a new location/project in Grass.  Since I  
am new to
both Linux/Ubuntu and Grass there are a nearly infinite ways to  
go wrong.  I
have Ubuntu 7.10 installed.  I used Synaptic to install Grass  
6.2.2 .  I
have been able to start Grass and play with the Spearfish and  
North Carolina
datasets.  I've made it to page 37 in "Open Source GIS A Grass  
GIS Approach,
3rd ed."  As interesting as North Carolina is, I yearn to create  
a map of
western New York.  But when I try to create a new project closer  
to home, I
get nowhere.  All the tutorials I've come across treat this as  
trivial, but

I'm stuck!

Starting Grass from the "Run Application" applet ("run in  
terminal" box
checked), starts Grass in the terminal window and a Grass  
Startup GUI window
appears.  Using the Browse button I enter "/home/matt/grass/ 
grassdata" in
the GIS Data Directory box.  The previous created directory map1  
appears in
the project location box and the Accessible Mapsets window is  
empty.  At
this point I've tried several things.  If before starting Grass  
I put a
Tiger shp file ( tgr36029lkA.shp) into map1, I'm unable to use  
it.  If I
click on EPSG codes and select 4326 and click "Define Location"  
it tells me
to restart Grass to find the created location.  When restarted  
the location

is not there.

Any ideas?  Especially how to start a new project using a Tiger  
shape

file? (Remember, novice).

Thanks,
Matt


Given what you've described, it seems that somehow you've gone too  
far down the directory tree. You've got your mapset appearing in  
the location list. This will be an invalid "location" because it  
does not contain a PERMANENT directory (i.e., mapset). Try backing  
up the tree one level. Your new location probably exists at the  
next level up.


Go back to browse in the data directory selection. It may be the  
difference between a single click and double click. But you want  
to get the proper directory in the directory selection dialog box.  
(In the case above, it should be /home/matt/grass/grassdata *IF*  
that is where your location directories are stored. That is, the  
nc_spm_07 directory should be inside /home/matt/grass/grassdata.)  
Then press OK to return to the startup screen.


At this point, you should seek nc_spm_07 on the left side and  
PERMANENT, landsat, sqlite, and user1 on the right side. If this  
is NOT what you see, redo your data directory selection until it  
IS what you see. At this point you can either 1) create a new  
mapset INSIDE nc_spm_07 (or other locaiton), or 2) create a new  
LOCATION inside your data directory.


You should not have to restart GRASS anymore to see a newly  
created location or mapset (this instruction is out of date  
AFAIK). If you cannot see a new location or mapset, try  
reselecting your data directory (i.e., the same one you are  
creating a location in).


There is very good online help on all this directly accessible  
from the startup screen by pressing the "Help" button.


Michael___
grass-user mailing list
[EMAIL PROTECTED]
http://lists.osgeo.org/mailman/listinfo/grass-user


Hi Micheal,

Thanks for your answer, but in my case the 'nc_spm_07' directory is  
not being created. The directory doesn't appear neither '/home/matt/ 
grassdata' and nor in '/home/matt'.
I tried the same with the gra

Re: [GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 30

2008-01-14 Thread Michael Barton
I understand about SWIG. Thanks for the clarification about the  
digitizer.


But what would the --with-wxpython switch actually do?

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 14, 2008, at 5:17 AM, Martin Landa wrote:


Hi,

2008/1/14, Michael Barton <[EMAIL PROTECTED]>:

[snip]

I added --with-wxpython option to configure script. wxPython  
requires

--with-python, also checks for python version >= 2.4 and wxpython >=
2.8.



Currently, the wxPython GUI needs a separate installation of Python
and wxPython. I don't think the Python SWIG interface makes any
difference to the GUI (or does it do something with the digitizing
module?). So what does this switch do?


--with-python can enable improved SWIG interface (swig/python) in the
future. For --with-wxpython you need to enable also --with-python
since wxPython requires Python of course. The wx digitization tool
also uses minimalistic SWIG interface, so swig is also needed. BTW,
the is no option --with-swig, should be?

Martin

--
Martin Landa <[EMAIL PROTECTED]> * 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] Python GUI requirements

2008-01-14 Thread Michael Barton

Agree. This was the basis of my question too.

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 14, 2008, at 7:28 AM, [EMAIL PROTECTED] wrote:



now gui/Makefile checks for wxPython instead of Python. wxPython  
stuff

is installed only if --with-wxpython is given.


I think Glynn's point was that the installation should simply  be
unconditional with no checks in gui/Makefile - the wxPython stuff  
is just
scripts and doesn't need Python to be installed on the compilation  
system

for the scripts to be processed in any way (unlike C compiling) - the
requirement for wxPython is only on the system that GRASS is run on  
so it

should be a runtime check rather than a comile-time check.

Of course if the wxPython stuff does require Python on the compilation
system, then what I've said is totally wrong...

Paul


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


[GRASS-dev] Re: [GRASS-user] Unable to create new project with Grass

2008-01-14 Thread Michael Barton

Jan,

Is EPSG location creation the only thing that fails? Can you create  
locations from georeferenced files and by specifying projection  
parameters?


I just tried creating a location from EPSG code 4326 and it worked  
fine in GRASS 6.3 compiled a few days ago. I don't know if this is a  
problem related to 6.2 or not


Glynn Clements discussed a problem with shared libraries in Linux  
that might or might not be a help. I am copying it below.


Michael
____
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

 shared library post ==
Date: Sun, 13 Jan 2008 23:34:52 +
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] Error creating new mapset
To: "Jose A. Ruiz-Arias" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii


Jose A. Ruiz-Arias wrote:


i have installed GRASS-6.2.3 from source code with no apparent  
errors during
configuration, compilation and installation. However, when i run  
grass and

try to create a new mapset i get next error:

g.region: error while loading shared libraries: libgdal.so.1:  
cannot open

shared object file: Error 40

In fact, when i was setting the projection parameters and chose a UTM
projection, the program did not ask me for the UTM zone, the  
ellipsoid and

the datum.

In the GRASS configure process I explicitely used the
flag --with-gdal=/usr/local/bin/gdal-config and there were no  
errors. I
checked for the shared library and it is placed in /usr/local/lib  
directory.


Before the GRASS installation, I installed the GDAL/OGR bundle from  
the source
code, with netcdf support, and the GRASS support disabled. Again,  
there were
no apparent errors. Next I installed the gdal-grass plugin (gdal- 
grass-1.4.3

with the following options:
configure --with-gdal=/usr/local/bin/gdal-config --with-grass=/usr/ 
local/grass-6.2.3)


I did not detect any problem during the installation of these  
bundles. Anyone

knows about the problem??



Most systems won't load shared libraries from /usr/local/lib without
some additional configuration.

For Linux, you need to either set the LD_LIBRARY_PATH environment
variable to a path which includes /usr/local/lib, or add
/usr/local/lib to /etc/ld.so.conf then run ldconfig (as root).

--
Glynn Clements <[EMAIL PROTECTED]>

===



On Jan 14, 2008, at 7:49 AM, Jan Schorn wrote:


Hi Michael,

creating mapsets in an existing locations is no problem, and  
everything in GRASS we did worked fine. Its possible to see the  
locations, mapsets and everything.
But it's still not posible to create a location using EPSG codes (y  
tried various, 4326 too) - neither the directory is created (GRASS  
versions: 32bit 6.2.3 and 64bit 6.2.2).
With QGIS there aren't any problems creating Locations. This was  
the only way i could create Locations with the Ubuntu-Packages.
I'm running GRASS compiled from source on one of the computers and  
there aren't any problems too.


Thanks for troubleshooting ;-)
Jan


Michael Barton escribió:
First, try an already created location. Put the location of one of  
the demo data sets into your grass data directory and try to see  
it. Once you can see it OK, quit GRASS (GUI and typing exit from  
the command line), restart GRASS, and try to create a mapset in  
the demo location. If that works, quit GRASS, restart GRASS, and  
try creating a dummy location using EPSG code.


Sorry for the complications, but this can help troubleshoot the  
problem.


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 14, 2008, at 2:04 AM, Jan Schorn wrote:


Michael Barton escribió:



On Jan 13, 2008, at 5:06 AM, [EMAIL PROTECTED]  
wrote:



Date: Sat, 12 Jan 2008 21:26:05 +
From: "Jan Schorn" <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] Unable to create new project with Grass
6.2.2 inUbuntu 7.1
To: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Hi, list
I installed GRASS 6.2.3 in about 14 computers with i368  
architecture and
Ubuntu 7.10 (Les-ejk repositorios). The only way to create a  
new Location is

using QGIS.
Using GRASS the error explained by Matt occurs.
¿Any ideas?

Thanks,
Jan


2008/1/11, Matt <[EMAIL PROTECTED]>:


I am unable to create a new location/project in Grass.  Since  
I am new to
both Linux/Ubuntu and Grass there are a nearly infinite ways  
to go wrong.  I
have Ubuntu 7.10 i

[GRASS-dev] Re: [GRASS-user] Unable to create new project with Grass

2008-01-14 Thread Michael Barton
This suggests a problem with g.proj, since both EPSG and georeferenced  
file methods use it for creating a location, but specifying parameters  
does not. This is beyond my area of expertise, but maybe someone else  
on the dev list can troubleshoot now.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 14, 2008, at 9:20 AM, Jan Schorn wrote:


Hi Michael,
creating Locations specifying projection parameters works fine.

Creating Locations from georeferenced file ( http://atlastenerife.es/TeIDE2/Descarga_Publica.do?fichero=830 
 ) causes an 'Error de la aplicación' ;-). Both versions, the 6.2.2  
(64 bit) and 6.2.3 (32 bit) one, are displaying the same error log  
(see below).

The file used doesn't make problems importing it into a location.

Good luck :-)
Jan


Error: /usr/bin/x-terminal-emulator: ...

*Details:*

/usr/bin/x-terminal-emulator: to set an icon, please use -name  
 and set a profile icon
/usr/bin/x-terminal-emulator: to set an icon, please use -name  
 and set a profile icon

  while executing
"exec -- $env(GISBASE)/etc/grass-xterm-wrapper -T g.proj -n g.proj - 
e $env(GISBASE)/etc/grass-run.sh g.proj -c georef=$filepath location= 
$fileLocation"

  invoked from within
".fileloc.def invoke"
  ("uplevel" body line 1)
  invoked from within
"uplevel #0 [list $w invoke]"
  (procedure "tk::ButtonUp" line 22)
  invoked from within
"tk::ButtonUp .fileloc.def"
  (command bound to event)




Michael Barton escribió:

Jan,

Is EPSG location creation the only thing that fails? Can you create  
locations from georeferenced files and by specifying projection  
parameters?


I just tried creating a location from EPSG code 4326 and it worked  
fine in GRASS 6.3 compiled a few days ago. I don't know if this is  
a problem related to 6.2 or not


Glynn Clements discussed a problem with shared libraries in Linux  
that might or might not be a help. I am copying it below.


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

 shared library post ==
Date: Sun, 13 Jan 2008 23:34:52 +
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] Error creating new mapset
To: "Jose A. Ruiz-Arias" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii


Jose A. Ruiz-Arias wrote:


i have installed GRASS-6.2.3 from source code with no apparent  
errors during
configuration, compilation and installation. However, when i run  
grass and

try to create a new mapset i get next error:

g.region: error while loading shared libraries: libgdal.so.1:  
cannot open

shared object file: Error 40

In fact, when i was setting the projection parameters and chose a  
UTM
projection, the program did not ask me for the UTM zone, the  
ellipsoid and

the datum.

In the GRASS configure process I explicitely used the
flag --with-gdal=/usr/local/bin/gdal-config and there were no  
errors. I
checked for the shared library and it is placed in /usr/local/lib  
directory.


Before the GRASS installation, I installed the GDAL/OGR bundle  
from the source
code, with netcdf support, and the GRASS support disabled. Again,  
there were
no apparent errors. Next I installed the gdal-grass plugin (gdal- 
grass-1.4.3

with the following options:
configure --with-gdal=/usr/local/bin/gdal-config --with-grass=/usr/ 
local/grass-6.2.3)


I did not detect any problem during the installation of these  
bundles. Anyone

knows about the problem??



Most systems won't load shared libraries from /usr/local/lib without
some additional configuration.

For Linux, you need to either set the LD_LIBRARY_PATH environment
variable to a path which includes /usr/local/lib, or add
/usr/local/lib to /etc/ld.so.conf then run ldconfig (as root).





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


[GRASS-dev] WinGRASS needs TclTk 8.4

2008-01-15 Thread Michael Barton

Moritz,

In accidental testing, we've discovered that WinGRASS won't run with  
TclTk 8.5. It needs 8.4. William Kyngesbury also ran into a problem  
with TclTk 8.5 for Mac.


Michael
______
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

[GRASS-dev] Re: WinGRASS needs TclTk 8.4

2008-01-15 Thread Michael Barton
Depending on how it's setup, it won't even start OR NVIZ fails (this  
is what happens on the Mac). I haven't tested it on Linux yet.


Michael
______
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 15, 2008, at 12:27 PM, Moritz Lennert wrote:


On 15/01/08 18:51, Michael Barton wrote:

Moritz,
In accidental testing, we've discovered that WinGRASS won't run  
with TclTk 8.5. It needs 8.4. William Kyngesbury also ran into a  
problem with TclTk 8.5 for Mac.


Thanks for the info. I put it into the README. Any idea what  
specifically fails with 8.5 ? And does it also fail in Linux ?


Moritz


Michael
______
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton




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


Re: [GRASS-dev] cvs>svn?

2008-01-15 Thread Michael Barton

On Jan 15, 2008, at 4:33 PM, [EMAIL PROTECTED] wrote:


Message: 8
Date: Tue, 15 Jan 2008 15:45:12 -0800
From: Dylan Beaudette <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] cvs>svn?
To: grass-dev@lists.osgeo.org
Cc: Martin Landa <[EMAIL PROTECTED]>, Paul Kelly
<[EMAIL PROTECTED]>,  GRASS developers list
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;  charset="iso-8859-1"

On Tuesday 15 January 2008, Hamish wrote:

Martin Landa wrote:

BTW it would be great to start migration webpages to Drupal. AFAIU
we are waiting for LDAP-Drupal synchronization(?).


Paul:

Would that mean updates to the website would have to be done through
a web-based interface? I'm not sure I'm keen on that. When making a
change to the website it's good to be able to grep to see where the
thing you are changing is mentioned, and change all occurences.


This is an important downside to using a CMS like Drupal. A global  
find /
replace is not easily implemented by default. It may be possible to  
add this

functionality through a 3rd party module.

Before supporting a move to Drupal I would still like to see  
prototypes
of the GRASS frontpage, download page, and since it's already  
begun the

screenshots page implemented. How will the final product look?

Markus:

http://grass-dev.osgeo.net


One thing I think is critical is that the changes are monitored in  
some
sort of SCM with change history including author, date, and commit  
log

message. Does drupal give access to change history?


I think that it is possible to have revisioned edits with Drupal,  
possibly

after enabling some module.




Personally I prefer the exactitude of the 'vim' + raw html approach,
and don't like presenting a blog-like page style for a project
homepage. But I look forward to seeing what the Drupal prototype will
look like, or 3rd party examples, and hope my worries can be  
relieved.


Here is an example of a user-powered Drupal site. There are a  
couple of
add-ons present for pretty-printing code snippets, etc. I would be  
happy to

comment on any other Drupal related questions.




Having said that I am all for lowering barriers to entry to allow  
more
helpers to contribute. But raw HTML is not very hard, and Markus's  
nice

CSS setup ensures a consistent and pretty look.



I felt this way too. Although, now I am starting to like the  
ability to easily
define a pile of terms which can be used to index / cross- 
reference / sort
pages on a Drupal site. This allow rapid navigation by concept  
rather than

static navigation approaches commonly used on web pages.


It would be good to experiment a bit with the new Drupal site, and  
if it is

not suitable we can always switch to something else.

Cheers,

Dylan


I didn't see a link to the Drupal site that Dylan mentioned. Here is  
one that we recently set up for a new international modeling group.  
It is still under construction, but you can get an idea of how it  
looks. There are a LOT of "themes" that you can apply. I suppose that  
means it is not too hard to create a theme, though I don't know how  
one does it.


<http://www.openabm.org>

Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 

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


[GRASS-dev] GRASS Drupal web site

2008-01-16 Thread Michael Barton

Wolf,

Where is the test site so I can take a look at it?

Note, I changed this thread name to something that is more descriptive  
of what it is.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 16, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Wed, 16 Jan 2008 10:19:37 +0200
From: Wolf Bergenheim <[EMAIL PROTECTED]>
Subject: [Fwd: Re: [GRASS-dev] cvs>svn?]
To: GRASS developers list 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 16.01.2008 02:55, Hamish wrote:

Martin Landa wrote:

BTW it would be great to start migration webpages to Drupal.


I guess the ideal is a good intuitive hierarchical structure with  
good

index/search/sort tools too- they aren't mutually exclusive. The
ability to limit the search to just the website or just a particular
mailing list would be nice (htDig?)



There is a module called organic groups in Drupal. I don't have a  
lot of
experience with them, but basically they can be a front-end to a  
mailing
list, just like Google groups. And that would mean that the mailing  
list

traffic would be in Drupal, and could be searched for. With the search
in Drupal you can limit the by category, and the organic groups would
show up as one. With organic groups people could post to the mailing
lists via our site, and also via email.



It would be good to experiment a bit with the new Drupal site, and  
if

it is not suitable we can always switch to something else.


agreed.



That is why I did set it up. I do think that we can have the best of
both worlds. Meaning that hard-core hacker like Hamish can continue to
edit the pages in raw xhtml, and on the same time someone else less
familiar with code can edit a page and post a message to the mailing
lists via the web interface.

--Wolf

--

<:3 ) Wolf Bergenheim ( 8:>



--

  |Humpty Dumpty sat on a wall
(o< --|Humpty Dumpty had a great fall
//\   |All the king's horses and all the king's men
V_/_  |Couldn't put Humpty together again.

Wolf Bergenheim



--

___


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


[GRASS-dev] Re: grass-user Digest, Vol 21, Issue 41

2008-01-16 Thread Michael Barton
In order to get an extension into the menu, you need to have an ASCII  
text file named xtnmenu.dat in $GISBASE/etc or somewhere else in the  
path specified by $GRASS_ADDON_ETC.


The specs for this file are as follows:

Lines that begin with a "#" are comments and not read
Menu description lines are

[menu level]:[menu item]:[command to call module]:[help string]

[menu level] is not implemented yet, but would allow for hierarchical  
menus. Just set it to 0
[menu item] is what actually shows up in the menu, UNLESS [menu item]  
== "separator". If it is called separator, it will create a menu  
separator as a horizontal rule.
[command to call module] should be in the proper format to initiate  
your module from TclTk. You can use run procedures available gis.m  
(see runandoutput.tcl)

[help string] is a text string for mouse-over help.

Hope this helps.

Michael
________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Jan 16, 2008, at 6:09 AM, [EMAIL PROTECTED] wrote:


Date: Wed, 16 Jan 2008 11:14:37 +0100
From: " Micha?l Rabotin " <[EMAIL PROTECTED]>
Subject: [GRASS-user] using Grass Extension Manager
To: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Hello Everybody
Thanks to Benjamin Ducke for the response
Now since I've installed GEM, I want to use it for all the scripts I
developped.
I've got 40 perl and shell scripts which are used for landscape
segmentation; Some procedures are independants but the the majority  
are used
on the control of a principal script. At this time, there is no  
graphical

interface only a terminal interface.
I want to use GEM to implement my scripts in the gis.m interface,  
is it the

right way to do it ?
I read the GEM documentation but it's a little harder for me to  
understand
the whole procedure. Is some already use GEM to do the same thing  
and can

explain to me some 'tricks' to begin ?
Thanks a lot
Mick


--
M.
-- next part --
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/ 
20080116/1209d885/attachment-0001.html




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


[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 43

2008-01-17 Thread Michael Barton

I put gmlib into $GISBASE/etc/gm

Seems that someone put it (or a reference to it) in $GISBASE/gtcltk/gm

I'll change this as soon as I can

Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 17, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Thu, 17 Jan 2008 11:05:00 -0500
From: "Patton, Eric" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] New 'About Grass' and 'About System' errors in
gis.m
To: <[EMAIL PROTECTED]>
Cc: grass-dev@lists.osgeo.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="iso-8859-1"

Hi,

These are a couple of new errors that I found today. Clicking  
the'About Grass' menu option in the
gis.m Help menu produces the following errors in a tcl/tk pop-up  
dialog, after which an empty

tcltk window opens with "About" in the titlebar:

wrong # args: should be "setfont source"
wrong # args: should be "setfont source"
   while executing
"setfont .helptext.frame $help_font"
   (procedure "Gm::helptext" line 14)
   invoked from within
"Gm::helptext {About GRASS} {-width 75} {-justify left} $text"
   (file "/usr/local/grass-6.3.svn/etc/gm/grassabout.tcl" line 96)
   invoked from within
"source /usr/local/grass-6.3.svn/etc/gm/grassabout.tcl"
   invoked from within
".#menubar.#menubar#menu7 invoke active"
   ("uplevel" body line 1)
   invoked from within
"uplevel #0 [list $w invoke active]"
   (procedure "tk::MenuInvoke" line 50)
   invoked from within
"tk::MenuInvoke .#menubar.#menubar#menu7 1"
   (command bound to event)

The 'About System' produces a new kind of error than the one  
reported a few weeks ago; when
this menu option is selected, the following error is printed to the  
system terminal:


Error in startup script: couldn't read file "/usr/local/ 
grass-6.3.svn/etc/gtcltk/gmlib.tcl": no such file or directory

   while executing
"source $env(GISBASE)/etc/gtcltk/gmlib.tcl"
   (file "/usr/local/grass-6.3.svn/etc/gm/tksys.tcl" line 16)

~ Eric.


--

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

End of grass-dev Digest, Vol 21, Issue 43
*


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


[GRASS-dev] GRASS-dev] New 'About Grass' and 'About System' errors in gis.m

2008-01-17 Thread Michael Barton



On Jan 17, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Thu, 17 Jan 2008 11:05:00 -0500
From: "Patton, Eric" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] New 'About Grass' and 'About System' errors in
gis.m
To: <[EMAIL PROTECTED]>
Cc: grass-dev@lists.osgeo.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="iso-8859-1"

Hi,

These are a couple of new errors that I found today. Clicking  
the'About Grass' menu option in the
gis.m Help menu produces the following errors in a tcl/tk pop-up  
dialog, after which an empty

tcltk window opens with "About" in the titlebar:

wrong # args: should be "setfont source"
wrong # args: should be "setfont source"
while executing
"setfont .helptext.frame $help_font"
(procedure "Gm::helptext" line 14)
invoked from within
"Gm::helptext {About GRASS} {-width 75} {-justify left} $text"
(file "/usr/local/grass-6.3.svn/etc/gm/grassabout.tcl" line 96)
invoked from within
"source /usr/local/grass-6.3.svn/etc/gm/grassabout.tcl"
invoked from within
".#menubar.#menubar#menu7 invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .#menubar.#menubar#menu7 1"
(command bound to event)

The 'About System' produces a new kind of error than the one  
reported a few weeks ago; when
this menu option is selected, the following error is printed to the  
system terminal:


Error in startup script: couldn't read file "/usr/local/ 
grass-6.3.svn/etc/gtcltk/gmlib.tcl": no such file or directory

while executing
"source $env(GISBASE)/etc/gtcltk/gmlib.tcl"
(file "/usr/local/grass-6.3.svn/etc/gm/tksys.tcl" line 16)

~ Eric.



Fixed now in the SVN

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 


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


[GRASS-dev] thematic mapper broken in GUI - how can I tell what what was changed

2008-01-21 Thread Michael Barton
I've just discovered that the thematic mapper is now broken in the  
GUI. How can I find out what the last change was in the SVN (or CVS if  
it was there)?


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

[GRASS-dev] nevermind

2008-01-21 Thread Michael Barton

I don't know what went wrong, but d.vect.thematic is NOT broken. Sorry.

Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

Re: [GRASS-dev] thematic mapper broken in GUI - how can I tell what what was changed

2008-01-22 Thread Michael Barton
Thanks very much Hamish. I want to save this someplace so that I can  
do this in the future too.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 21, 2008, at 8:20 PM, Hamish wrote:


Michael Barton wrote:


How can I find out what the last change was in the SVN


go to http://trac.osgeo.org/grass/browser/grass/trunk
click on [scripts/]
click on [d.vect.thematic/]
click on the REV number of the file you want (opp to ViewCVS)

or try ViewCVS mirror:

http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/grass/trunk/?root=grass-osgeo

to view changes it's just like in MediaWiki.


alt. method from the command line

cd trunk/scripts/d.vect.thematic
svn up
svn log description.html




(or CVS if it was there)?


CVS change history has been ported, so it's there too back to 1999.
only rev. numbers are different.


Hamish





  


Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ




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


[GRASS-dev] missing awk in WinGRASS

2008-01-23 Thread Michael Barton
I've run into a problem that a number of scripts require awk and the  
installation of WinGRASS we've put in the lab doesn't have it. Is  
there a special way to install MSys to make sure we've got this?


Michael

________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



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

Re: [GRASS-dev] [grass-code R][585] Display of current pixel value of pointer in gis.m (in addition to the coordinates on the lower right corner)

2008-01-23 Thread Michael Barton


On Jan 23, 2008, at 8:32 AM, [EMAIL PROTECTED] wrote:


Date: Tue, 22 Jan 2008 19:52:55 +0100 (CET)
From: 
Subject: [GRASS-dev] [grass-code R][585] Display of current pixel
	value of	pointer in gis.m (in addition to the coordinates on the  
lower

right corner)
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8

code R item #585, was opened at 2008-01-22 18:52
Status: Open
Priority: 3
Submitted By: Nikos Alexandris (nikosa)
Assigned to: Nobody (None)
Summary: Display of current pixel value of pointer in gis.m (in  
addition to the coordinates on the lower right corner)

Issue status: None
GRASS component: None
Operating system: None
Operating system version:


Initial Comment:
Is it difficult to display in gis.m (on the lower right corner) the  
value of the pixel that is currently "touched" by the  
(mouse-)pointer, along with the coordinates?


It wouldn't be necessary to Query the whole time just for a quick- 
view!




In order to find out the value of the spatial data that is under the  
pixel, you have to query it. There are different query routines for  
raster and vector maps.


Michael
__________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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


[GRASS-dev] Re: missing awk in WinGRASS

2008-01-23 Thread Michael Barton

Hmmm.

Looking in the bin directory in msys, there IS an awk and gawk.exe.

So why would scripts complain about not having it? Is there something  
in the batch file that needs to be set so that GRASS knows that it's  
there?


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 23, 2008, at 8:32 AM, Moritz Lennert wrote:


On 23/01/08 16:06, Michael Barton wrote:
I've run into a problem that a number of scripts require awk and  
the installation of WinGRASS we've put in the lab doesn't have it.  
Is there a special way to install MSys to make sure we've got this?


I thought that awk is part of the basic msys installation, but if  
not, you can just install the gawk-3.1.5-MSYS-1.0.11-1.tar.bz2  
package which you can find at http://sourceforge.net/project/showfiles.php?group_id=2435 
.


Moritz


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


[GRASS-dev] Re: missing awk in WinGRASS

2008-01-23 Thread Michael Barton

OK. We can do that. Thanks.

Is msys needed for any other aspects of GRASS -- i.e., is it required  
to run it? Or is it only needed if you want to do the scripts?


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 23, 2008, at 12:37 PM, Moritz Lennert wrote:


On 23/01/08 17:32, Michael Barton wrote:

Hmmm.
Looking in the bin directory in msys, there IS an awk and gawk.exe.
So why would scripts complain about not having it? Is there  
something in the batch file that needs to be set so that GRASS  
knows that it's there?


As it says in the readme: "in order for shell scripts to work, you  
will have to add msys' lib and bin directories to your path in the  
grass63.bat file."


Concretely this means uncommenting (i.e. deleting the 'rem') the  
last of the following lines in grass63.bat and adapting it to your  
installation


rem Path to utilities used by some scripts, such as awk, sed, etc
rem (adjust to where you installed msys, gnuwin32, or other similar  
utilises)

rem set set PATH=%PATH%;c:\msys\1.0\bin;c:\msys\1.0\lib

Moritz


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


[GRASS-dev] Re: missing awk in WinGRASS

2008-01-23 Thread Michael Barton

Is GnuWin32 a better option than msys for this?

Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 23, 2008, at 12:47 PM, Moritz Lennert wrote:


On 23/01/08 20:35, Michael Barton wrote:

OK. We can do that. Thanks.
Is msys needed for any other aspects of GRASS -- i.e., is it  
required to run it? Or is it only needed if you want to do the  
scripts?


Only for the scripts. And even for those it doesn't have to be msys.  
You could install the individual components (a shell like bash, awk,  
sed, etc) separately, e.g. from GnuWin32. As long as these tools are  
in your path, this should work.


Moritz


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


[GRASS-dev] why d.vect.thematic won't run on WinGRASS - d.mon problem

2008-01-23 Thread Michael Barton
In order for d.vect.thematic to run in the GUI (the only way it will  
work in WinGRASS), it has to start and stop the PNG monitor.


To do this, it has to run d.mon--i.e., d.mon start=png and d.mon  
stop=png.


However, d.mon will not run in WinGRASS, probably because it does not  
have x11. I am betting that d.mon ALWAYS checks for an x11 monitor  
when it attempts to do something. However, it doesn't really need one  
if it is running the PNG monitor (or perhaps doing some other tasks  
that are not related to starting, stopping, or selecting xmons).


If this is correct, is there a way to disable this check so that d.mon  
can start and stop the PNG driver without checking for an xmon?


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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

Re: [GRASS-dev] Re: missing awk in WinGRASS

2008-01-23 Thread Michael Barton


On Jan 23, 2008, at 6:28 PM, Glynn Clements wrote:


The longer-term solution is to abandon Bourne shell in favour of a
popular cross-platform interpreted language (i.e. Python). Apart from
making it easier to write portable scripts, it would eliminate the
need to use external utilities (sed, awk, bc, etc) for simple tasks
(e.g. having to invoke awk or bc to perform floating-point
arithmetic).


I definitely agree, though recognize the amount of work that will be  
to translate all GRASS scripts.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

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


  1   2   3   4   5   6   7   8   9   10   >