Re: [GRASS-dev] gis.m command tool
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
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
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
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
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
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
++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
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
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
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
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
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
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
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]
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
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
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]
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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!
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!
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!
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
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!
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!
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!
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
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
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!
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
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
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
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
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 scriptsincluding 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 ?
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 ?
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 ?
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
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
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?
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?
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
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
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
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
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
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
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)
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
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
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
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)
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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