Re: [GRASS-user] Re: CYGWIN
Glynn: I don't think that we will be able to make any progress on this until someone who can reproduce it can get a backtrace out of gdb. Luigi: Is this the place to start from? http://grass.osgeo.org/wiki/Compile_and_Install see http://grass.osgeo.org/wiki/Bugs Is it a matter of trying compiling on Cygwin? I assume that gdb is the debugger of gcc. I'm not sure if a recompile in needed. Glynn, are those binaries compiled with -g and not stripped? gdb is the GNU debugger. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with grib support for GRASS 6.4
Tom: I think this must be the problem; I will check it when I get back into work… Hamish, are you saying that translation occurs even in r.in.gdal with GRIB data sets, or only with the work-around by converting the grib to geotiff with gdal_translate? any all gdal ops, it's a problem in gdal's grib driver. It's easily compensated for (with r.region) once you know about it, but be aware of it and optimally be able to confirm that a) the adjustment is really needed and b) it worked correctly. (and please help test/confim the patches in the gdal bug tracker if you can!) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Le vendredi 04 décembre 2009 à 14:16 -0700, Michael Barton a écrit : Markus, This is helpful. Much more so than simply those that ask 'why can't we do things the way we did'. Michael, as far as I am concerned by your remark, I just wish to distinguish my attitude from that of a potential pure fastidious/demanding consumer : I just keep very cautious from giving advices when I feel like being a too modest contributor... To finish off with my contribution, I initially bewailed the loss of some functionalities that straightly threatened some home-made pieces of code I use daily and intensively. I rencently worked for a customer who needed to upgrade a series a ArcInfo AML routines I wrote for him some years ago for AI7.2 and which did not work properly now on AI9. I praised him that developing his future personalized solutions on GRASS would be a guarantee of long-lasting, reliabilty, and so on... oops ! Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Markus wrote: I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. fwiw I find ^r a bit confusing to use. (user ignorance of the sublties I'm sure..) I much prefer to use PgUp/PgDn after typing the partial command, create a file called ~/.inputrc containing: set prefer-visible-bell # Bind page up/down wih history search - \e[5~: history-search-backward \e[6~: history-search-forward I got really used to this in the matlab console (up/down arrow there) and it hurt not to have it in bash until I learned the above trick. for my 2c I think it's ultimately a losing battle to try and reimplement bash (poorly, to quote the famous phrase) and we should ship a minimal wx based ximgview/qiv/display app with auto refesh on file update and minimal g.region/d.zoom/d.where (right click menu only, strictly k.i.s.s. like d.mon). I doubt it would take much effort to write or maintain as long as we don't try to make it much more than a window into the data. then hardcore folks can use csh/bash/emacs/whatever as they like without the overhead of a gui. it's too much to ask users to find a download an image viewer of their own, especially when it's probably less than a few hundred lines of code to ship our own wx based version. for one thing I'd consider running that tunneled over ssh+X to a remote number cruncher, but not a real GUI. a while ago while traveling and only a borrowed win2k + puTTY to work with I rigged up a system where the png driver wrote the display image across to a apache public dir which I could reload in the web browser. not ideal, but it worked. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
Hamish wrote: Is it a matter of trying compiling on Cygwin? I assume that gdb is the debugger of gcc. I'm not sure if a recompile in needed. Glynn, are those binaries compiled with -g and not stripped? The Cygwin binaries are stripped. Normally, I'd mention that you can still get a backtrace from stripped binaries. But in retrospect, the stackdump file says probably corrupted stack, so I don't think that you could get a backtrace even if the binaries weren't stripped. At this point, I'm out of ideas. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Vincent wrote: I praised him that developing his future personalized solutions on GRASS would be a guarantee of long-lasting, reliabilty, and so on... oops ! backwards compatibility since grass 6.0.0 in March 2005 is no mistake. it suggests that any code written for grass 7 will work for a similar time frame. and there is nothing stopping anyone from running grass 6.x well into the future, or continue with grass 5.4 for that matter. to limit ourselves from any change would guarantee obsolescence. the great trick is to compress all that good change into a single instant which are far appart, rather than to allow continual change with no stability. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
I very much agree with Markus. The main point is that a command line interface is *much* faster than a GUI, once you have learned to use it. This can take a long time to learn (take the VIM editor for example), and for most people that is simply not worth it. When you have it in your fingers however, it really is much more efficient. I still use Grass54 for digitizing, even if I have to convert the vector maps into the new format, because digitizing, the most labour-intensive job there is in GIS, gets done much more efficiently with the left hand using the keyboard, and the right hand using the mouse. That program has disappeared, but Markus's example illustrates perfectly the case for the actual version of GRASS. I understand that programmers have limited time and resources, and I certainly agree that these should be spent on the GUI: it's important for many more people than the bunch of old-hand command line hackers. I *would* plead however to leave as much of the old functionality in place as possible. If I understand Glynn's posting on this subject correctly however, this will be very difficult, as the Vask library has been removed (why?), and all mouse interaction has been dropped from the display commands. If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases? Jan Markus Neteler wrote: On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton michael.bar...@asu.edu wrote: Roy, I guess you haven't been following quite all of this discussion. Sincerely, I am in the same boat apparently, see below. You can still run all module commands in GRASS from any terminal. You can TYPE d* commands into the command line interface of the GUI and have the resulting maps displayed in the GUI display canvas. You can also type the d.* commands into any xterminal and have grass maps saved as graphic files to view. These can be viewed automatically with free image viewers (like d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal behavior is all that has been dropped. And that's the key issue here. Personally, I need (beside d.rast/d.vect) - d.zoom - d.measure - d.where to interactively work with the maps. GRASS analysis consists in my case of a significant amount of graphically digging in the maps. For interactive use, there is a much more sophisticated interface that exists now--that is, you can do a lot more interaction than you could do before. True. But it is not yet as efficient as the old method. To better explain (and please don't get me wrong, you have done a tremendous job with the new GUI!!, note that I am one of these funky cmd line power users :-): - to visualize a, say, raster map which I have been looking at 3 months ago, I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. - Using the GUI, I have to use the icon/find the menu entry, select the map in the map selector (problem here, my MODIS LST time series have 5 * 1460 maps per mapset, that would be 7300 maps to scroll through!), then accept it and have it listed in the map list. Still I don't see it because the Render button isn't activated by default... (see my other poll about this some time ago). So, using the GUI here is unrealistic. Sure, I am a strange user :) Besides simply not being GRASS 4 or 5 (which are still available to be run), what functionality are you missing? The speed of displaying maps and the ease of querying them. If there was a command line possibility to control the wxGUI, I would most likely make the switch to GRASS 7. Speed really matters for me. I am routinely analysing 11,000+ maps and regularly work in 3 projects in one morning, so the command line history is a real lifesaver here to also recall what I have done (and to eventually morph it to a document). The new GUI, integrated with the command line possibility to throw in the maps, would be the perfect combination. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Hamish, you're right, anyone can still freely use former but stable versions of Grass (like Jan does with grass5 for digitizing) for his particular purposes. Looking towards future I just figure out it's high time I began learning python ;-) Anyway, thank you all for this interesting discussion, Vincent. Le samedi 05 décembre 2009 à 02:51 -0800, Hamish a écrit : Vincent wrote: I praised him that developing his future personalized solutions on GRASS would be a guarantee of long-lasting, reliabilty, and so on... oops ! backwards compatibility since grass 6.0.0 in March 2005 is no mistake. it suggests that any code written for grass 7 will work for a similar time frame. and there is nothing stopping anyone from running grass 6.x well into the future, or continue with grass 5.4 for that matter. to limit ourselves from any change would guarantee obsolescence. the great trick is to compress all that good change into a single instant which are far appart, rather than to allow continual change with no stability. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
GRASS is very cautious with regards to upgrades--some would say too cautious. Great care is taken to maintain all backward compatibility within a version. That is, code written for version 6.0 should run on version 6.4rc5. However, the program needs to evolve too. This happens between major version numbers. For example, the vector file structure changed dramatically between version 5 and 6--for the better AFAIC because it made for the default link between vector objects and attribute tables. But this still will break some scripts. Between 6 and 7 there will be changes to the raster file structure. Also, the display architecture is being cleaned up a lot. A great many GRASS modules called in scripts dating from version 4 will still run in version 7. You can translate files created in version 4 to version 7. One of the changes in 7 is to get rid of an old interactive mode that affected a subset of the d* modules. This mode has restricted GRASS to a tiny fraction of the computers used by people today. I'm a die-hard Mac user and I like Linux, but I realize that even together, these constitute a small proportion of the OS used by people across the world. Even for me, running d.mon and d.rast was handy, but this is easily replaced. The interactive parts of d.measure, d.zoom, etc have been replaced by an alternate way of interacting with a mouse. Scripts which depended on these for interaction were depending on an interaction mode and display architecture dating to the 1980's. In computer years, that must be at least a century or two ;-) It's amazing that GRASS has maintained that architecture so long, but it has done so at increasing cost for functionality and access by users. The changes in architecture with version 7 have been discussed on the dev list and in the WIKI for over two years. The point is that to me at least this seems like a LOT of stability for computer software. Recently, I discovered some files that I had forgotten to upgrade from Microsoft Word ver. 3 in the early 1990's. So far, I have not been able to find anything to read these files. A GRASS file from that era can be read and many scripts written in that era will still run. Most of those that won't run can be made to do so with minimal tweaking. At the same time, GRASS has been modified to also work with a wider variety of scripting languages, with a special emphasis on Python--an easy to use open source language widely used in the sciences. So IMHO your advice to the client is not at all off the mark. Michael On Dec 5, 2009, at 2:11 AM, Vincent Bain wrote: Le vendredi 04 décembre 2009 à 14:16 -0700, Michael Barton a écrit : Markus, This is helpful. Much more so than simply those that ask 'why can't we do things the way we did'. Michael, as far as I am concerned by your remark, I just wish to distinguish my attitude from that of a potential pure fastidious/demanding consumer : I just keep very cautious from giving advices when I feel like being a too modest contributor... To finish off with my contribution, I initially bewailed the loss of some functionalities that straightly threatened some home-made pieces of code I use daily and intensively. I rencently worked for a customer who needed to upgrade a series a ArcInfo AML routines I wrote for him some years ago for AI7.2 and which did not work properly now on AI9. I praised him that developing his future personalized solutions on GRASS would be a guarantee of long-lasting, reliabilty, and so on... oops ! Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thank you Michael and others, I really appreciate the time you allow to clarify these points. I am convinced the discussion will have been benefic to many other users. Yours, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 5, 2009, at 2:27 AM, Hamish wrote: Markus wrote: I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. fwiw I find ^r a bit confusing to use. (user ignorance of the sublties I'm sure..) I much prefer to use PgUp/PgDn after typing the partial command, create a file called ~/.inputrc containing: set prefer-visible-bell # Bind page up/down wih history search - \e[5~: history-search-backward \e[6~: history-search-forward I got really used to this in the matlab console (up/down arrow there) and it hurt not to have it in bash until I learned the above trick. for my 2c I think it's ultimately a losing battle to try and reimplement bash (poorly, to quote the famous phrase) and we should ship a minimal wx based ximgview/qiv/display app with auto refesh on file update and minimal g.region/d.zoom/d.where (right click menu only, strictly k.i.s.s. like d.mon). I doubt it would take much effort to write or maintain as long as we don't try to make it much more than a window into the data. then hardcore folks can use csh/bash/emacs/whatever as they like without the overhead of a gui. This is not understanding what is involved to do this. It IS a considerable effort to write and maintain a second interactive display that is a retro mimic of an old xmon. It is is probably not a considerable effort to write and maintain a script that wraps display commands with an image viewer with automatic refresh. Keep in mind that the syntax would not be d.rast ... But it would still be a command line display. This is not a GUI. That's why it is doable with minimal effort. The difficulty is creating a display that IS another GUI--that is a display interface that allows the user to use a mouse to control the display and other module functions like changing the region. Having written two of these, I have some idea of what is involved. Doing the menus for the 300+ commands is trivial. Creating a mouse-driven zoom box that changes the display to zoom in or out of a map is a lot of work and code. I'm afraid that I don't have the time or inclination to create and maintain a separate retro GUI for a few users, no matter how much I love you all. And I still can't understand why yet another mouse-operated GUI is needed. Also, none of the comments I've yet seen on the list suggests that anyone has actually tried the command line interface that Martin and I DID build into the wxPython GUI at the request of the dev crowd. It is not an attempt to reimplement bash, but to offer an alternate way to interact with GRASS by typing commands. This DOES leverage the display and mouse-interaction code we have already built and maintain. You can type d.* commands and have maps displayed. You can then interact with the displayed maps with a mouse to zoom, measure, and query. Since you are going to use a mouse anyway, it is faster to click one button on the display you are already working with than to type d.measure from the keyboard. It is considerably easier to create and maintain a way to type commands from within the existing GUI than it is to create a 2nd GUI. However this CLI can't be improved without input. Michael it's too much to ask users to find a download an image viewer of their own, especially when it's probably less than a few hundred lines of code to ship our own wx based version. for one thing I'd consider running that tunneled over ssh+X to a remote number cruncher, but not a real GUI. a while ago while traveling and only a borrowed win2k + puTTY to work with I rigged up a system where the png driver wrote the display image across to a apache public dir which I could reload in the web browser. not ideal, but it worked. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Sat, Dec 5, 2009 at 10:27 AM, Hamish hamis...@yahoo.com wrote: Markus wrote: I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. fwiw I find ^r a bit confusing to use. (user ignorance of the sublties I'm sure..) I am working on many different remote systems, so I try to learn the necessary minimum rather than focusing on a personal optimization (sure I agree that that is handy if you work on your only one or a few machines). ... for one thing I'd consider running that tunneled over ssh+X to a remote number cruncher, but not a real GUI. a while ago while traveling and only a borrowed win2k + puTTY to work with I rigged up a system where the png driver wrote the display image across to a apache public dir which I could reload in the web browser. not ideal, but it worked. Right, working over ssh in GRASS is very common for me (70% of overall time, often even over unstable connections). So I learned to love screen to not crash the GRASS session. The d.* approach consumes little resources only, that's why I like it so much... Will later comment more on a previous mail of Michael. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 5, 2009, at 3:14 AM, Jan Hartmann wrote: I very much agree with Markus. The main point is that a command line interface is *much* faster than a GUI, once you have learned to use it. This can take a long time to learn (take the VIM editor for example), and for most people that is simply not worth it. When you have it in your fingers however, it really is much more efficient. I still use Grass54 for digitizing, even if I have to convert the vector maps into the new format, because digitizing, the most labour- intensive job there is in GIS, gets done much more efficiently with the left hand using the keyboard, and the right hand using the mouse. That program has disappeared, but Markus's example illustrates perfectly the case for the actual version of GRASS. A point on digitizing. If you haven't tried it, you should take a look at the digitizing that Martin has built into the new GUI. Because it has hot-key equivalents for all buttons, you CAN digitize with your right hand on the mouse and left on the keyboard. It also has a lot of contextual menus that you access by right clicking while you digitize rather than having to move to a separate text area like in 5.4. I understand that programmers have limited time and resources, and I certainly agree that these should be spent on the GUI: it's important for many more people than the bunch of old-hand command line hackers. I *would* plead however to leave as much of the old functionality in place as possible. If I understand Glynn's posting on this subject correctly however, this will be very difficult, as the Vask library has been removed (why?), and all mouse interaction has been dropped from the display commands. Glynn has done a good job of describing why these libraries have been removed from a programming perspective. I just want to note that in GRASS 7, if you want to do GRASS completely via commands (i.e., that is NON-interactive), you can do so. Type commands from a system terminal or from the terminal built into the GUI. If you want to do GRASS completely interactively without typing commands, you can do so using the pulldowns, scrolling lists, buttons, etc of the wxPython GUI. If you want to type commands for all non-interactive uses of GRASS but want to interact with displayed maps using a mouse, you can do so in the GUI. So far, the only concrete function that I've yet read that is missing from these varied ways to interact with GRASS is a command-line autocompletion that Markus mentioned. There may be other missing functionality but no one has detailed any. If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases? This is not something I do any coding for, but AFAIK, GRASS will continue to be able to read GRASS files from the past, either directly or via translation. Michael Jan Markus Neteler wrote: On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton michael.bar...@asu.edu wrote: Roy, I guess you haven't been following quite all of this discussion. Sincerely, I am in the same boat apparently, see below. You can still run all module commands in GRASS from any terminal. You can TYPE d* commands into the command line interface of the GUI and have the resulting maps displayed in the GUI display canvas. You can also type the d.* commands into any xterminal and have grass maps saved as graphic files to view. These can be viewed automatically with free image viewers (like d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal behavior is all that has been dropped. And that's the key issue here. Personally, I need (beside d.rast/d.vect) - d.zoom - d.measure - d.where to interactively work with the maps. GRASS analysis consists in my case of a significant amount of graphically digging in the maps. For interactive use, there is a much more sophisticated interface that exists now--that is, you can do a lot more interaction than you could do before. True. But it is not yet as efficient as the old method. To better explain (and please don't get me wrong, you have done a tremendous job with the new GUI!!, note that I am one of these funky cmd line power users :-): - to visualize a, say, raster map which I have been looking at 3 months ago, I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. - Using the GUI, I have to use the icon/find the menu entry, select the map in the map selector (problem here, my MODIS LST time series have 5 * 1460 maps per mapset, that
Re: [GRASS-user] grass70 and display monitor
I actually do appreciate the input. I would like to make GRASS highly usable for as broad an audience as possible--from mouse junkies to command-line geeks. But this needs to also face pragmatic realities of available time and effort of the volunteers that do the coding. How can we get the most bang for the volunteer buck? Michael On Dec 5, 2009, at 8:28 AM, Vincent Bain wrote: Thank you Michael and others, I really appreciate the time you allow to clarify these points. I am convinced the discussion will have been benefic to many other users. Yours, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 5, 2009, at 8:48 AM, Markus Neteler wrote: On Sat, Dec 5, 2009 at 10:27 AM, Hamish hamis...@yahoo.com wrote: Markus wrote: I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. fwiw I find ^r a bit confusing to use. (user ignorance of the sublties I'm sure..) I am working on many different remote systems, so I try to learn the necessary minimum rather than focusing on a personal optimization (sure I agree that that is handy if you work on your only one or a few machines). ... for one thing I'd consider running that tunneled over ssh+X to a remote number cruncher, but not a real GUI. a while ago while traveling and only a borrowed win2k + puTTY to work with I rigged up a system where the png driver wrote the display image across to a apache public dir which I could reload in the web browser. not ideal, but it worked. Right, working over ssh in GRASS is very common for me (70% of overall time, often even over unstable connections). So I learned to love screen to not crash the GRASS session. The d.* approach consumes little resources only, that's why I like it so much... Can the d.* rendered to a small footprint image viewer work in this setting? Michael Will later comment more on a previous mail of Michael. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] An idea for a lightweight GRASS CLI
So here is an idea for a lightweight GRASS CLI to run from a system terminal 1) a Python script that will set the display variables and launch an image viewer with autorefresh as Glynn has mentioned. It would use the Python input function to allow for the user to type multiple d.rast and d.vect commands. 2) a script named g.zoom. This script runs g.region and will reset the computational (and display) region by a positive or negative percentage around the center point or optionally around a point whose coordinates the user inputs 3) a script named g.pan. This script runs g.region to shift the computational (and display) region by a percent or by a unit value in some cardinal direction Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Ossimplanet Interaction between Grass/Qgis (osgeo - gsoc 2009)
Hi All Please apologize me for cross posting, i finally finished to write a web page to describe the work done this summer for the osgeo google summer of code project, this the link : http://web.me.com/epiesasha/PlanetSasha/Project.html it include a short description of the main app and include instructions on how to install it on ubuntu karmic (my thanks to Pirmin Kalberer to make avaiable .deb packages for ossim and ossimplanet) plese felle free to try the code and send me feedback! the code is in active development, any feedback is really welcome! it can give me a great help to fix bugs, add enanchments ... and motivate myself to continue its development ;-) Special thanks to my mentor Mark Lucas and all the ossim-dev team! Ciao, Massimo. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Michael Barton wrote: A point on digitizing. If you haven't tried it, you should take a look at the digitizing that Martin has built into the new GUI. Because it has hot-key equivalents for all buttons, you CAN digitize with your right hand on the mouse and left on the keyboard. It also has a lot of contextual menus that you access by right clicking while you digitize rather than having to move to a separate text area like in 5.4. Ah, I hadn't realized that. Is that in GRASS 7? I don't use GRASS enough to compile the unstable versions, but now it's the first thing I am going to do on Monday. Takes away my only major problem with GRASS. BTW, I see that I asked for this last February (http://lists.osgeo.org/pipermail/grass-user/2009-February/048986.html). Don't know if that was the reason for the hot-keys, but thanks anyway. If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases? This is not something I do any coding for, but AFAIK, GRASS will continue to be able to read GRASS files from the past, either directly or via translation. It's not that important for me any more now, but perhaps older versions of GRASS could be bundled as Qgis in OsGeo4W, where you can install one or more of four versions. For Linux, you could think of distributing them like the FWTools utilities: each version in a single directory tree, including all the dependencies (and even a complete Python). That way, different versions can be used without conflicts between library versions. At least, that is the way I manage them on the cluster I am working on, to get quick functional copies on different nodes. Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GIS and GPU
Hi, I'am curious to know if there is any development is using GPU to accelerate some tasks in GIS, like raster calculations. I have an Nvidia gpu and found pyCUDA parallel computation very interesting. Is there any paper in this subject to read? Thanks. Pablo Torres Carreira _ Com o Internet Explorer 8 você tem seu contéudo favorito em poucos cliques. Conheça! http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag5utm_campaign=IE8___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
