Re: [GRASS-user] grass70 and display monitor
Thank you for your answers and advices. Glynn, with your method based on displaying grass files on the fly in a viewer, I guess all d.* interactive commands will fail, won't they ? Deep down I want to know how much I will have to adapt some shell scripts I wrote for grass6* when my users migrate to grass70. My feeling on this point with care for durability of the application - and I think grass is mostly used by people in search of customization - is it would be nice that be maintained these fundamentals... To my mind it is one of the most important benefits of open source apps. On the other hand I am not aware enough of the constraints that lead to drop x monitors. Bye, Vincent Le jeudi 03 décembre 2009 à 06:00 +, Glynn Clements a écrit : Vincent Bain wrote: my question could be insane but I am wondering if there is an equivalent command to d.mon in grass70. In several man pages I saw a reference to d.frame but it seems not be implemented yet. Or will grass70 give up with x monitors ? considering one still can launch grass in text mode, I guess there might be a way to open a graphical device. GRASS 7.0 does not support monitors. The various display drivers are libraries against which the display library is linked. There are no persistent monitor processes as in 6.x, meaning that there is no persistence of state between d.* commands, so no d.frame, d.font etc. All rendering parameters are set via environment variables. Some of these are listed in the variables manual page, while others are listed in the manual pages for the various drivers. You can approximate the pre-7.0 workflow using an image viewer which automatically refreshes the display whenever the file changes. For X, you can use the ximgview program, e.g.: export GRASS_PNGFILE=map.bmp d.erase ximgview export GRASS_PNG_MAPPED=TRUE export GRASS_PNG_READ=TRUE # more d.* commands ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Questions related with wxpython modules in Windows
Hi,
2009/12/3 Franz Schiller franzschiller1...@gmail.com:
Ok, now it makes sense. i.ortho.photo just like i.class requires X monitors
so they are not available to windows. Right?
right.
About vector digitalization. In the menu it doesn't appear in wxpython menu
but if a write v.digitizer it opens a wxpython menu and when I run it runs
in tcltk. is this what is expected to happen?
I guess you mean v.digit - it's TCL/TK-based digitizer. wxGUI
digitizer is intergrated into the GUI, you can start it from map
display toolbar ('digitize') or from map layer popup menu ('start
editing').
Martin
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Questions related with wxpython modules in Windows
Hi, 2009/12/3 Franz Schiller franzschiller1...@gmail.com: [...] Are these options blocked only in Windows or also in Linux? Thanks for your help No, wxGUI vector digitizer should work on Linux and Mac OS X. Martin PS: Please keep discussion on ML. -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Fwd: [GRASS-user] Questions related with wxpython modules in Windows
Greetings all After a few emails with Martin let me summarize this (and now for all grass user community): - v.digit is working in TCLtk in windows - digitizer is working in Wxpython in Linux and OS Mac - digitizer is not working in wxpython in windows (the option to start editing is not avaiable) and when I select digitizer (in map window combobox) a error window appeared saying Unable to start vector digitizer. The vdigit python extension was not found or loaded properly, Swithcing back to 2D display Module. Details: No module named grass6_wxvdigit. But when I write v.digit in wxpyhon (in Windows) I get the tcltk vector digitizer. Just confirm me that this is an adequate sum of the digitizer situation for windows users Thanks Martin for your help Franz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Questions related with wxpython modules in Windows
Hi, 2009/12/3 Franz Schiller franzschiller1...@gmail.com: After a few emails with Martin let me summarize this (and now for all grass user community): - v.digit is working in TCLtk in windows - digitizer is working in Wxpython in Linux and OS Mac - digitizer is not working in wxpython in windows (the option to start editing is not avaiable) and when I select digitizer (in map window combobox) a error window appeared saying Unable to start vector digitizer. The vdigit python extension was not found or loaded properly, Swithcing back to 2D display Module. Details: No module named grass6_wxvdigit. But when I write v.digit in wxpyhon (in Windows) I get the tcltk vector digitizer. Just confirm me that this is an adequate sum of the digitizer situation for windows users it's right. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Supervised classification without i.class
Hi, 2009/12/3 Luis Lisboa luislisboa1...@gmail.com: I saw a few messages talking about i.class not being available to WindowsGRASS. Next January I will give a few classes of Remote Sensing in the University and I was planning to use GRASS6.4 in the classes. One of the major modules is Supervised Classification. Those classes will be taught using Windows OS. According to GRASS book (I bought it :) ), I can perform supervised radiometric classification using digitized training areas (i.class) (I) or using auxiliary data (II). About (I) I realized that i.class options are not available in Windows. Besides i.class is there any alternative to have an interactive selection of training areas? I am afraid not -- only non-interactive approach. Digitize areas, rasterize vector areas and use i.gensig. About (II). Is it possible to use a ESRI shapefile with all areas as an input and then converted to shapefile? Import data to native format using v.out.ogr or link data using v.external (some problems can occur). The OGR interface is being improved in GRASS 7. Another question/request is if there is any manual/tutorial explaining classification procedure in GRASS6.4? I am using GRASS for remote sensing course at my university (only in Czech) [1], classification [2, 3]. Martin [1] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracování_obrazových_dat#Cvi.C4.8Den.C3.AD [2] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracování_obrazových_dat_-_cvičení_10 [3] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracování_obrazových_dat_-_cvičení_11 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Supervised classification without i.class
2009/12/3 Martin Landa landa.mar...@gmail.com: [2] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracování_obrazových_dat_-_cvičení_10 [3] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracování_obrazových_dat_-_cvičení_11 sorry, here are the correct links [2] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracov%C3%A1n%C3%AD_obrazov%C3%BDch_dat_-_cvi%C4%8Den%C3%AD_10 [3] http://gama.fsv.cvut.cz/wiki/index.php/153YZOD_Zpracov%C3%A1n%C3%AD_obrazov%C3%BDch_dat_-_cvi%C4%8Den%C3%AD_11 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Hi John and others, (and for easy reference as well to whom it may concern) I think the discussion that best corresponds to my question is here : http://lists.osgeo.org/pipermail/grass-dev/2009-August/045399.html Vincent. Le mercredi 02 décembre 2009 à 10:47 -0800, John C. Tull a écrit : And for easy reference, here is the thread: http://lists.osgeo.org/pipermail/grass-dev/2009-November/047135.html Cheers, John On Dec 2, 2009, at 9:46 AM, Vincent Bain wrote: Thank you Michael, I found the thread... Yours, Vincent Le mercredi 02 décembre 2009 à 10:37 -0700, Michael Barton a écrit : There is no use of xmonitors in GRASS 7. There is a recent and ongoing discussion of alternatives on the Dev list. Look for the Shell scripts thread. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 2, 2009, at 10:34 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Wed, 02 Dec 2009 18:22:15 +0100 From: Vincent Bain b...@toraval.fr Subject: [GRASS-user] grass70 and display monitor To: GRASS user list grass-user@lists.osgeo.org Message-ID: 1259774535.11312.12.ca...@vincent-desktop Content-Type: text/plain Dear grass users, my question could be insane but I am wondering if there is an equivalent command to d.mon in grass70. In several man pages I saw a reference to d.frame but it seems not be implemented yet. Or will grass70 give up with x monitors ? considering one still can launch grass in text mode, I guess there might be a way to open a graphical device. thank you for your commentaries on this question, Vincent. ___ 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Supervised classification without i.class
Hello Martin thanks for your reply. I am afraid not -- only non-interactive approach. Digitize areas, rasterize vector areas and use i.gensig. Ok. But If I try to have Linux or Mac OS machine, I could use i.class right? About your links, ehehehe unfortunely Czech is not in my language domain (English, Spanish, French, Catalan). But I will try to get some ideas :) Thanks Import data to native format using v.out.ogr or link data using v.external (some problems can occur). The OGR interface is being improved in GRASS 7. Uhm I'm planning to use 6.4 (it has binaries). has anyone tried with success this operation? Thanks Best regards Luis Lisboa Universitat Pompeu Fabra, Barcelona ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Supervised classification without i.class
Hi Luis, I have imported shape files in grass 6.4 using v.in.ogr. Not a big hassle. One way to acquire training areas for the supervised classification is to digitize them using either the tcl/tk digitizer or, what I find easiest, the QGis digitizer. QGis is free and can create shape files. I'm not sure (never tested it) but I believe you can even use QGis to create Grass vector files. Once the vectors are done, just convert them to raster, use i.gensig to extract the signatures and then use i.maxlik to classify the image. cheers Daniel On Thu, Dec 3, 2009 at 9:33 AM, Luis Lisboa luislisboa1...@gmail.com wrote: Hello Martin thanks for your reply. I am afraid not -- only non-interactive approach. Digitize areas, rasterize vector areas and use i.gensig. Ok. But If I try to have Linux or Mac OS machine, I could use i.class right? About your links, ehehehe unfortunely Czech is not in my language domain (English, Spanish, French, Catalan). But I will try to get some ideas :) Thanks Import data to native format using v.out.ogr or link data using v.external (some problems can occur). The OGR interface is being improved in GRASS 7. Uhm I'm planning to use 6.4 (it has binaries). has anyone tried with success this operation? Thanks Best regards Luis Lisboa Universitat Pompeu Fabra, Barcelona ___ 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] Converting from Lat/Long to Projection -- REALLY SOLVED
On Thu, 3 Dec 2009, Glynn Clements wrote: 1. The default input format has X (easting) followed by Y (northing). You need to use the -r switch if the northing comes first. Glynn, That's what I thought. I tried the '-r' switch, too, based on the example in the man page. Originally I had the easting first but changed to match the man page example. It is the explanation below that was the real source of my issues with the tool. 2. In the absence of a trailing E or W, positive eastings are east of the prime meridian. You need either a leading - or a trailing W for eastings in the western hemisphere. This is where I went off the tracks. I kept looking at the example in the man page and saw the different formats. However, what I saw was that thowe with a leading '-' or trailing 'W' were expressed in decimal degrees, not degrees-minutes-seconds. Based on that I did not use either the prefix or suffix since my values are in DMS. Thank you very much for clarifying. The man page is ambiguous and when used as a learning tool rather than a reference leads to invalid results. Very much appreciated, Rich ___ 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 Bain wrote: Glynn, with your method based on displaying grass files on the fly in a viewer, I guess all d.* interactive commands will fail, won't they ? There are no interactive d.* commands in 7.0. The 7.0 display architecture doesn't have any facility to query a mouse. Any modules which depended upon such functionality have either been removed entirely or have had the corresponding functionality removed. Deep down I want to know how much I will have to adapt some shell scripts I wrote for grass6* when my users migrate to grass70. My feeling on this point with care for durability of the application - and I think grass is mostly used by people in search of customization - is it would be nice that be maintained these fundamentals... To my mind it is one of the most important benefits of open source apps. This isn't going to change. If you want interaction, you need to either extend the GUI, or leverage existing functionality (e.g. by using the digitiser to create a vector map or the georectifier to create GCPs, then using this data as input). On the other hand I am not aware enough of the constraints that lead to drop x monitors. The interactive features made it impractical to build a decent GUI on top of the display commands. Additionally, the monitor-based architecture meant that it took an excessive amount of work to implement relatively minor improvements, as well as making debugging difficult. Oh, and none of it worked on Windows. -- 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] Converting from Lat/Long to Projection -- NOT SOLVED
On Thu, 3 Dec 2009, Glynn Clements wrote: 1. The default input format has X (easting) followed by Y (northing). You need to use the -r switch if the northing comes first. 2. In the absence of a trailing E or W, positive eastings are east of the prime meridian. You need either a leading - or a trailing W for eastings in the western hemisphere. Glynn, There's another discrepancy in the man page I should point out for posterity: the syntax summary's last item. Notice: SYNOPSIS cs2cs [ -eEfIlrstvwW [ args ] ] [ +opts[=arg] ] [ +to [+opts[=arg]] ] file[s] This indicates that one can use the command in a file (a shell script). But, that does not work; it just sits there with no response. Apparently, the command runs only from the command line. Thanks again for your clarifications, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landscape connectivity
Hi Markus, Am Donnerstag 03 Dezember 2009 01:02:00 schrieb Pablo Carreira: Hi Markus M., after a fast look at Urban Keitt here is my sugestions: a)Create a single central vector point for each patch. b)Connect that vector to an MySQL database. c)create the columns ID, X, Y, NHABDIST, NHABID. d)v.to.db the coordinates of the central points. e)Now you have a a database with all you need to make the calculations: 1) how far away is the nearest other habitat patch 2) what's the id of the nearest habitat patch With SQL, basic math and a script calculate for each single point the distance for the all other points, then make the script select the nearest and input the distance and the id in the NHABDIST, NHABID. PostGIS gives you the power to use the boundaries of your patches. It provides amongst others the two functions ST_Distance [1] (calculates the shortest distance between two polygon boundaries) and ST_DWithin [2] (giving all other patches within a certain distance). Vector data can be imported easily with ogr2ogr. The rest is again standard sql. [1] http://postgis.refractions.net/documentation/manual-1.4/ST_DWithin.html [2] http://postgis.refractions.net/documentation/manual-1.4/ST_Distance.html cheers, robert ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thanks for your reply, May I be considered bothersome, but was it really impossible to achieve (like in grass65) the development of a wxGUI (which I really enjoy too) while keeping the complete set of historical command line environment ? Le jeudi 03 décembre 2009 à 14:40 +, Glynn Clements a écrit : Vincent Bain wrote: Glynn, with your method based on displaying grass files on the fly in a viewer, I guess all d.* interactive commands will fail, won't they ? There are no interactive d.* commands in 7.0. The 7.0 display architecture doesn't have any facility to query a mouse. Any modules which depended upon such functionality have either been removed entirely or have had the corresponding functionality removed. Deep down I want to know how much I will have to adapt some shell scripts I wrote for grass6* when my users migrate to grass70. My feeling on this point with care for durability of the application - and I think grass is mostly used by people in search of customization - is it would be nice that be maintained these fundamentals... To my mind it is one of the most important benefits of open source apps. This isn't going to change. If you want interaction, you need to either extend the GUI, or leverage existing functionality (e.g. by using the digitiser to create a vector map or the georectifier to create GCPs, then using this data as input). On the other hand I am not aware enough of the constraints that lead to drop x monitors. The interactive features made it impractical to build a decent GUI on top of the display commands. Additionally, the monitor-based architecture meant that it took an excessive amount of work to implement relatively minor improvements, as well as making debugging difficult. Oh, and none of it worked on Windows. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Supervised classification without i.class
Since creating training areas is not such an intensive digitizing operation as full-scale vector creation, perhaps v.edit could be used in a wxPython replacement for i.class. An advantage of v.edit is that it works cross-platform now. Michael On Dec 3, 2009, at 8:06 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Thu, 3 Dec 2009 11:33:27 + From: Luis Lisboa luislisboa1...@gmail.com Subject: Re: [GRASS-user] Supervised classification without i.class To: Martin Landa landa.mar...@gmail.com Cc: grass-user@lists.osgeo.org, grass-wind...@lists.osgeo.org Message-ID: b557f5480912030333t428370e2q80e57d3f2d846...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hello Martin thanks for your reply. I am afraid not -- only non-interactive approach. Digitize areas, rasterize vector areas and use i.gensig. Ok. But If I try to have Linux or Mac OS machine, I could use i.class right? About your links, ehehehe unfortunely Czech is not in my language domain (English, Spanish, French, Catalan). But I will try to get some ideas :) Thanks Import data to native format using v.out.ogr or link data using v.external (some problems can occur). The OGR interface is being improved in GRASS 7. Uhm I'm planning to use 6.4 (it has binaries). has anyone tried with success this operation? Thanks Best regards Luis Lisboa Universitat Pompeu Fabra, Barcelona ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 44, Issue 13
On Dec 3, 2009, at 8:06 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Thu, 03 Dec 2009 16:06:07 +0100 From: Vincent Bain b...@toraval.fr Subject: Re: [GRASS-user] grass70 and display monitor To: Glynn Clements gl...@gclements.plus.com Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: 1259852767.6278.6.ca...@vincent-desktop Content-Type: text/plain; charset=utf-8 Thanks for your reply, May I be considered bothersome, but was it really impossible to achieve (like in grass65) the development of a wxGUI (which I really enjoy too) while keeping the complete set of historical command line environment ? 1) xmons don't work at all under windows 2) you can work completely via the command line and create all the scripts you want. In fact, scripting works better under GRASS 7 than prior versions because of a more consistent command interface 3) if you want interactive, we've spent hundreds of hours and 10's K of code developing an up-to-date interactive environment instead of one based on 1980's technology Not sure why we should try to recreate a retro 1980's kind of limited interaction too. All coding takes time and effort to develop and maintain. Currently there are only 2 people willing to do GUI coding, even though it is a code base many orders of magnitude greater than any module. I disagree about the majority of GRASS users wanting only to use it only in customized script-based or command based environments. I've had some version of the following conversation too many times to count. [Researcher/student/professional after one of my talks or demonstrations] Hey that was pretty cool. You know, I tried GRASS some years ago, but ummm... I gave up because I couldn't really figure out how to get it to do things. [Me] Have you looked at it recently? Here, check it out [Them] Wow. That looks a lot different from what I saw. I think that would work for my [fill in the blank] project. How do I get it? Part of the reason there are a larger number of command-line/scripting users with GRASS is that 1) it used to run only on Linux or Unix and people using that OS (especially in the past) were self-selected command-line, compiling, coding users, and 2) anyone who didn't want to run GRASS that way tried it and gave up. If we want to keep the user base confined to that audience, then we need to get rid of the GUI altogether and focus on enhancing commands. If we want to have a large and diverse user base that can make use of GRASS for a wide variety of geospatial tasks and for teaching, then we need a highly interactive, up-to-date GUI as well as maintaining command-line scripting use. I think that there is a need for a high-end geospatial data management, analysis, and visualization program like GRASS. However, most of these potential users will not be people like me (and much of the old user base) who use commands, write code, and customize GRASS into scripts. Cheers Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Converting from Lat/Long to Projection -- NOT SOLVED
On Thu, 3 Dec 2009, Rich Shepard wrote: SYNOPSIS cs2cs [ -eEfIlrstvwW [ args ] ] [ +opts[=arg] ] [ +to [+opts[=arg]] ] file[s] Or, that the data can be in a file but the command is entered on the CLI. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.horizon problems with large DEM
Hi Joshua, On Tuesday 01 December 2009 14:14:07 Markus Neteler wrote: Joshua, On Mon, Nov 30, 2009 at 5:50 PM, Joshua Campbell jcampbell@gmail.com wrote: Markus, Thanks for the input. I reviewed the r.sun page and unfortunately r.sun doesn't provide the specific horizon angle provided by r.horizon. My goal is not to compute solar irradiance. ok. I was able to run r.horizon on a subset that was ~4900x9900. The DEM I'm trying to use in 3x78000 (but is has quite a bit of null values). Do you know if there is pixel dimension limit to r.horizon? I suspect that you have hit the 2GB limit but... Hit a similar limit with v.outlier but that was probably just over c.1100x1100 All I could do was divide my area into 70 regions. I am using the 64-bit package available through the Ubuntu site -- would it make a difference if I built the code from source? ... if it is *really* a 64 bit binary that should not matter. If 32bit, then there is the --enable-largefile flag to configure the GRASS source code before compilation. Do anyone know of a script that would iteratively set a region, compute r.horizon (with a buffer), move the region, and r.patch the resulting horizon files? If anyone is interested in writing this script, we could discuss compensation (contact directly at jcampbell.geo at gmail.com) Sounds good :) Unfortunately I have no time... best Markus Still trying to learn the scripting thing myself, the 70 regions was a bore and I don't want to have to do that again. So sorry, can't help. Though regions and r.patch is the way when scripting and memory limits are a problem. Have you tried using a mask so the NULL values are ignored? Does that help? or mean less regions? John ___ 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] set region from display
2009/12/3 Alfredo Alessandrini alfreal...@gmail.com: There is a shell command for set computational region from display? I guess you are referring to wxGUI. This options is available only from Map Display Window. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] set region from display
On Thu, 3 Dec 2009, Alfredo Alessandrini wrote: There is a shell command for set computational region from display? Alfredo, Are you referring to g.region? Use it specifying the map name; e.g.: g.region vect=streams or g.region rast=elevation HTH, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 44, Issue 14
On Dec 3, 2009, at 10:04 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Thu, 3 Dec 2009 17:51:59 +0100 From: Alfredo Alessandrini alfreal...@gmail.com Subject: [GRASS-user] set region from display To: grass-user@lists.osgeo.org Message-ID: d2c05c5a0912030851g1bdf0ec1u66613d19b7cf3...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, There is a shell command for set computational region from display? Thanks, Alfredo There is not. But this is a potentially useful script to be used within the display environment. However, in order to create the display you want to do it this way, you will need to use a mouse (drag a magnification up or down box). So it is not much effort to then pick the relevant menu item off the display. A possibly more useful command line script would be to set the display to match the computational region. You can always set the computational region from the command line using g.region of course. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Copying Map from One Location to Another
Apparently, g.copy works only within the current location/mapset. I have a sites map and attribute data in grassbase/sitesLCC/rbs/ that I want to copy to grassbase/Oregon/rbs. I also have a raster DEM that I want to copy to that same location/mapset. Please point me to the appropriate commands. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: CYGWIN
Dear Glynn and Markus, I found no follow-up to this message of last November 17 so I am replying to this one. On windows 7 and using a fresh Cygwin/GRASS install as per instructions at http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ I start Cygwin shell - startxwin.sh - grass64 -tcltk The startup GUI pops up, I select a mapset, and press enter GRASS as usual. I get a very similar error to that reported by Markus below, i.e.: 5 [main] g.gisenv 4772 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 358850 [main] g.gisenv 4772 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump (every time you get same message with different numbers) Also, by calling GRASS in the following way: grass64 -tcltk 2 logGRASS.txt The content of the log is /usr/local/grass-6.4.0RC5/etc/Init.sh: line 837: tput: command not found Hope this help better diagnosis. My apologies if I missed follow-up to this thread. Kind regards, Luigi Date: Tue, 17 Nov 2009 12:54:46 + From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-user] CYGWIN To: Markus Neteler nete...@osgeo.org Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: 19202.40214.211883.542...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii Markus Neteler wrote: Starting grass64/cygwin with -tcltk leads to 13 [main] g.gisenv 2100 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 78803 [main] g.gisenv 2100 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump Subsequently the GUI isn't started (the tcltk startup screen comes up well). Running on command line: g.gisenv returns the settings as it should. Running on command line: g.region -p returns to command line without printing anything. Perhaps there is a version conflict with the proj libraries? All of the above work for me. -- 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 Bain wrote: May I be considered bothersome, but was it really impossible to achieve (like in grass65) the development of a wxGUI (which I really enjoy too) while keeping the complete set of historical command line environment ? Very little is actually impossible, but the disadvantages (in terms of both effort and detriment to the end product) far outweigh the advantages. -- 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] Converting from Lat/Long to Projection -- NOT SOLVED
Rich Shepard wrote: 1. The default input format has X (easting) followed by Y (northing). You need to use the -r switch if the northing comes first. 2. In the absence of a trailing E or W, positive eastings are east of the prime meridian. You need either a leading - or a trailing W for eastings in the western hemisphere. Glynn, There's another discrepancy in the man page I should point out for posterity: the syntax summary's last item. Notice: SYNOPSIS cs2cs [ -eEfIlrstvwW [ args ] ] [ +opts[=arg] ] [ +to [+opts[=arg]] ] file[s] This indicates that one can use the command in a file (a shell script). But, that does not work; it just sits there with no response. Apparently, the command runs only from the command line. The ... file[s] means that it you can specify the names of input files as arguments. There's no inherent reason why cs2cs won't work in a script, but the cs2cs manpage won't explain any particular scripting language; those have their own manpages. In any case, cs2cs isn't part of GRASS, but of PROJ: http://trac.osgeo.org/proj/ PROJ is required by GRASS, so most of the developers (and experienced users) have some familiarity with it, but we aren't in a position to make changes. -- 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] Copying Map from One Location to Another
Rich Shepard wrote: Apparently, g.copy works only within the current location/mapset. I have a sites map and attribute data in grassbase/sitesLCC/rbs/ that I want to copy to grassbase/Oregon/rbs. I also have a raster DEM that I want to copy to that same location/mapset. Please point me to the appropriate commands. You can't *copy* maps between locations, as different locations typically have different projections. You can re-project maps between locations with r.proj (raster) and v.proj (vector). -- 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] Copying Map from One Location to Another
On Thu, 3 Dec 2009, Glynn Clements wrote: You can't *copy* maps between locations, as different locations typically have different projections. You can re-project maps between locations with r.proj (raster) and v.proj (vector). Since both the source and destination locations have the same projections I thought there was a GRASS copy command. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Copying Map from One Location to Another
You can re-project maps between locations with r.proj (raster) and v.proj (vector). Since both the source and destination locations have the same projections I thought there was a GRASS copy command. see also: http://n2.nabble.com/link-to-datasets-from-other-locations-td3185792.html#a3207135 http://n2.nabble.com/raster-data-from-one-location-to-another-td1886064.html#a1886064 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
Luigi Ponti wrote: On windows 7 and using a fresh Cygwin/GRASS install as per instructions at http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ I start Cygwin shell - startxwin.sh - grass64 -tcltk The startup GUI pops up, I select a mapset, and press enter GRASS as usual. I get a very similar error to that reported by Markus below, i.e.: 5 [main] g.gisenv 4772 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 358850 [main] g.gisenv 4772 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump Can you post the contents of the g.gisenv.exe.stackdump file? Also, by calling GRASS in the following way: grass64 -tcltk 2 logGRASS.txt The content of the log is /usr/local/grass-6.4.0RC5/etc/Init.sh: line 837: tput: command not found This is harmless; the only consequence is that the terminal window won't be cleared. The tput program is in the ncurses package, which isn't otherwise required (the libraries required by curses-based programs are in a separate libncurses9 package). Hope this help better diagnosis. My apologies if I missed follow-up to this thread. I don't think that there has been any follow-up. -- 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] Re: CYGWIN
On 04/12/2009 07:58, Glynn Clements wrote: Luigi Ponti wrote: On windows 7 and using a fresh Cygwin/GRASS install as per instructions at http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ I start Cygwin shell - startxwin.sh - grass64 -tcltk The startup GUI pops up, I select a mapset, and press enter GRASS as usual. I get a very similar error to that reported by Markus below, i.e.: 5 [main] g.gisenv 4772 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 358850 [main] g.gisenv 4772 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump Can you post the contents of the g.gisenv.exe.stackdump file? Here it is: 9888 [main] g.gisenv 3672 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 11805 [main] g.gisenv 3672 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Thanks for your reply, Luigi Also, by calling GRASS in the following way: grass64 -tcltk 2 logGRASS.txt The content of the log is /usr/local/grass-6.4.0RC5/etc/Init.sh: line 837: tput: command not found This is harmless; the only consequence is that the terminal window won't be cleared. The tput program is in the ncurses package, which isn't otherwise required (the libraries required by curses-based programs are in a separate libncurses9 package). Hope this help better diagnosis. My apologies if I missed follow-up to this thread. I don't think that there has been any follow-up. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
