Re: [GRASS-user] exporting only a table from a vector
On Friday 01 August 2008, Nikos Alexandris wrote: > On Fri, 2008-08-01 at 16:19 -0300, Milton Cezar Ribeiro wrote: > [...] > > > 2008/8/1, Nikos Alexandris <[EMAIL PROTECTED]>: > > [...] > > > Hi Milton. > > > > If you use sqlite as DBMS you can open your sqlite.db file > > with > > sqlitebrowser and export your table of interest as a .csv > > file. Later > > you can import for example in openoffice for further editing. > > [...] > db.select should do what you want. I use it regularly to make CSV file for export. Cheers, -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] exporting only a table from a vector
On Fri, 2008-08-01 at 16:19 -0300, Milton Cezar Ribeiro wrote: [...] > > > 2008/8/1, Nikos Alexandris <[EMAIL PROTECTED]>: [...] > Hi Milton. > > If you use sqlite as DBMS you can open your sqlite.db file > with > sqlitebrowser and export your table of interest as a .csv > file. Later > you can import for example in openoffice for further editing. [...] Milton, I assume it works for you this way. Anyway, I am writing back to note that it was not my intention NOT to cc in the list. For some reason I don't hit always the reply-to-all button lately :-? Cheers, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.rast.edit issues
On Aug 1, 2008, at 4:01 PM, Glynn Clements wrote: Adam Dershowitz wrote: I am trying to use d.rast.edit and I can't get it to work properly. If I open it, either from the menu, or from the command line, it seems to open fine, but the size of my overview window is much larger then the size of my screen, so I can't see much of the window. If I resize the window then I don't get any scroll bars, so that doesn't help. That's a bug in d.rast.edit. The overview window consists of three parts: the canvas (the portion containing the map), the vertical scrollbar and the horizontal scrollbar. The canvas is supposed to grow or shrink along with the top-level window, leaving the scrollbars with a fixed width (vertical) or height (horizontal). However, the weights were set on the wrong window, so everything tries to remain a fixed size. I have committed a fix in the current development version, but you can fix the problem locally by changing lines 157-158 of grass-6.3.0/etc/d.rast.edit.tcl from: grid rowconfigure. 0 -weight 1 grid columnconfigure . 0 -weight 1 to: grid rowconfigure.overview 0 -weight 1 grid columnconfigure .overview 0 -weight 1 With that change, the scrollbars should remain visible if the overview window is shrunk. -- Glynn Clements <[EMAIL PROTECTED]> That did it! Thank you. --Adam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.rast.edit issues
Adam Dershowitz wrote: > I am trying to use d.rast.edit and I can't get it to work properly. > If I open it, either from the menu, or from the command line, it seems > to open fine, but the size of my overview window is much larger then > the size of my screen, so I can't see much of the window. If I resize > the window then I don't get any scroll bars, so that doesn't help. That's a bug in d.rast.edit. The overview window consists of three parts: the canvas (the portion containing the map), the vertical scrollbar and the horizontal scrollbar. The canvas is supposed to grow or shrink along with the top-level window, leaving the scrollbars with a fixed width (vertical) or height (horizontal). However, the weights were set on the wrong window, so everything tries to remain a fixed size. I have committed a fix in the current development version, but you can fix the problem locally by changing lines 157-158 of grass-6.3.0/etc/d.rast.edit.tcl from: grid rowconfigure. 0 -weight 1 grid columnconfigure . 0 -weight 1 to: grid rowconfigure.overview 0 -weight 1 grid columnconfigure .overview 0 -weight 1 With that change, the scrollbars should remain visible if the overview window is shrunk. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] XTF reader neede - triton format for sonar
Thanks Thierry for answering. AFAIK the XTF I've been given were tranformed form original KEB files. If I'm not wrong these formats are produced by Knudsen systems. I new about MBsystem. As they say on the site, I hope they will support XTF "sooner or later...". In the meanwhile I try to explain what I need: I need to vectorize the sonar echograms in an automatized way (I have about 300 files with dozens of "pings" each one), to extract the thickness of soft loam/clay deposits of some lake beds. So, my echograms show the vertical lines of the single "pings". For every ping I would like to extract the "first arrive" (the point where a signal above a threshold appear for the first time on the vertical) and the point when the signal decreases lower then another threshold (before signal decayes because of power loss). The problem is that I'm not such a good programmer! :-) I know sogtware for seismic datas that can do it, but it's the first time I work with sonars data, and this formats in particular. The alternative is to pick the 3000 points by hand, and measure the thickness for each segment! I'll let you know if I make useful steps. Giovanni 2008/8/1 Thierry Schmitt <[EMAIL PROTECTED]>: > Hi Giovanni > > There is nothing free to read XTF format that I know of. The format is > freely available on triton's website. The format has become a standard de > facto. However it is still difficult to get a really standard xtf file in > between the manufacturer of sonar processing software. > My advice would be > > 1) knowing the name of the application that acquired the sonar data. > 2) have a quick look at MBsystem which is the only sonar processing software > free as free beer!! It won't read xtf but you might find a way to find a > common denominator. > > I ll be glad to know how you proceed as I might be of better help if you are > more specific (acquisition software, sonar) > > Regards > > I G. Allegri a écrit : >> >> Hi list, >> I'm facing the need to process some sonar files in XTF (eXtensible >> Triton Format), but I can't find anything as OS to do it. >> Does anyone have experience with such a format? >> >> XTF References: >> >> http://www.tritonimaginginc.com/site/content/public/downloads/FileFormatInfo/Xtf%20File%20Format_X24.pdf >> http://woodshole.er.usgs.gov/operations/sfmapping/sonar_xtf.htm >> >> Free (as free beer) reader: >> http://www.knudsenengineering.com/html/software/postsurvey.htm >> >> Thanks, >> Giovanni >> ___ >> 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] v.info vs. r.info: different region output format
Sebastian Holler pisze: > v.info -g precip_30ynormals north=36.49917 south=33.99472 east=-75.62194 west=-84.02389 top=1615.44 bottom=2.438400 > r.info -g elev_ned_03arcsec north=35:54:40.66N south=35:35:17.334885N east=78:27:08.335106W west=78:49:17.33W Is there any reason for the different outputs or is this a bug? Not a bug but a "bad feature". Although the curent behaviour is not good, I'm affraid it cannot be changed during GRASS 6 devel line not to brake software that might depend on it. Please fill a defect report in Trac and the issue maybe will be fixed in GRASS 7. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.rast.edit issues
I am trying to use d.rast.edit and I can't get it to work properly. If I open it, either from the menu, or from the command line, it seems to open fine, but the size of my overview window is much larger then the size of my screen, so I can't see much of the window. If I resize the window then I don't get any scroll bars, so that doesn't help. So I can't figure out how to get to the lower 3/4 of my image. The edit window itself seems fine, but I can't get get it to select the correct part of the image, since I can't move to it in the overview window. What might or might not be relevant is that the only menu item that appears on either window is on the edit window I have a File menu with Save and Exit. Am I missing something? Is there any way to force the size of the window to stay on my screen? Or to force it to just show a different section? I could edit the different parts at different times if I could get to that "lower" area at all. I did try changing the region and the default region to see if that would allow me to choose a different part of the image, with no luck at all. I am using the kyngchaos mac 6.3 binary builds with the newest Mac X11: 2.3.0 and the tcltk interface. Thanks, --Adam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] XTF reader neede - triton format for sonar
Hi Giovanni There is nothing free to read XTF format that I know of. The format is freely available on triton's website. The format has become a standard de facto. However it is still difficult to get a really standard xtf file in between the manufacturer of sonar processing software. My advice would be 1) knowing the name of the application that acquired the sonar data. 2) have a quick look at MBsystem which is the only sonar processing software free as free beer!! It won't read xtf but you might find a way to find a common denominator. I ll be glad to know how you proceed as I might be of better help if you are more specific (acquisition software, sonar) Regards I G. Allegri a écrit : Hi list, I'm facing the need to process some sonar files in XTF (eXtensible Triton Format), but I can't find anything as OS to do it. Does anyone have experience with such a format? XTF References: http://www.tritonimaginginc.com/site/content/public/downloads/FileFormatInfo/Xtf%20File%20Format_X24.pdf http://woodshole.er.usgs.gov/operations/sfmapping/sonar_xtf.htm Free (as free beer) reader: http://www.knudsenengineering.com/html/software/postsurvey.htm Thanks, Giovanni ___ 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] v.info vs. r.info: different region output format
Hi list, I've tried to create bounding boxes for all layers of a given location with an extern python script. This script parses the output from "v.info -g " resp. "r.info -g ". But I noticed, that in a location with a geographic crs, the region outputs (esp. the unit formats) of vector and raster layers differs from each other. v.info prints the region in decimal degrees (DD) whereas r.info produces an output in degrees,minutes,seconds (DMS). For example (nc_ll location from www.grassbooks.org; EPSG:4001): > v.info -g precip_30ynormals north=36.49917 south=33.99472 east=-75.62194 west=-84.02389 top=1615.44 bottom=2.438400 > r.info -g elev_ned_03arcsec north=35:54:40.66N south=35:35:17.334885N east=78:27:08.335106W west=78:49:17.33W Is there any reason for the different outputs or is this a bug? For parsing both ouputs with external tools, it would be better if the formats were equal. Regards, Sebastian H. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] exporting only a table from a vector
Dear all, I have a vector map with its attributes on GRASS and I would like to export only the table (not the vector), and select some fields during the export. Is there a way of do it on GRASS? Kind regards miltinho astronauta brazil ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] can't click a button in wxGUI = 7 years old GTK bug?
Hi, Some of you might have noticed a problem with wxPython GRASS GUI that sometimes you could not click some button again without moving out of it's "area of control" and back (e.g. you can't press Run button in a module's GUI the second time not having moved the cursor somewhere outside of it and back). It is highly likely that it's been the same bug that was reported 7 (seven) years ago for GTK and just recently fixed. Dig the whole story [1]. Is it really the same thing like I suppose? [1]http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-bug-56070.html Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
On Fri, 2008-08-01 at 15:29 +0200, G. Allegri wrote: > A collegue sent me this ticks to run OSSIM on Ubuntu 7.10: > > > http://trac.osgeo.org/ossim/wiki/Ubuntu-7.10Build > > after every make make install, give a "ldconfig" and start another > shell to continue the compilation. > > in /etc/ld.so.conf.d/ > > I've exported the following libs : > > /usr/lib > /usr/local/lib > /home/sasha/GIS/ossim/ossim/lib > > within a file "ossim.conf" > -- > > Yet I've never found the time to try it... > > Giovanni I've been trying in the past and today again... but no luck. It's not an easy process. I wonder how this affects the status of OSSIM as an osgeo tool? Shouldn't all osgeo packages be installable in most major platforms? Well, this is a question for another list. Cheers, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] XTF reader neede - triton format for sonar
Hi list, I'm facing the need to process some sonar files in XTF (eXtensible Triton Format), but I can't find anything as OS to do it. Does anyone have experience with such a format? XTF References: http://www.tritonimaginginc.com/site/content/public/downloads/FileFormatInfo/Xtf%20File%20Format_X24.pdf http://woodshole.er.usgs.gov/operations/sfmapping/sonar_xtf.htm Free (as free beer) reader: http://www.knudsenengineering.com/html/software/postsurvey.htm Thanks, Giovanni ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
A collegue sent me this ticks to run OSSIM on Ubuntu 7.10: http://trac.osgeo.org/ossim/wiki/Ubuntu-7.10Build after every make make install, give a "ldconfig" and start another shell to continue the compilation. in /etc/ld.so.conf.d/ I've exported the following libs : /usr/lib /usr/local/lib /home/sasha/GIS/ossim/ossim/lib within a file "ossim.conf" -- Yet I've never found the time to try it... Giovanni 2008/8/1 Nikos Alexandris <[EMAIL PROTECTED]>: > On Fri, 2008-08-01 at 12:01 +0200, Maciej Sieczka wrote: >> Nikos Alexandris pisze: >> > how do Open Source Professionals image normalisation for aerial >> > photos... let's say 300 photos? I cannot imagine that people sit-down >> > and extract psuedoinvariant targets for 300 photos (except they are >> > payed a lot for that). >> >> Nikos, >> >> Have you looked at OSSIM? Not that I'm sure it provides the tool, but >> seems likely. >> > > Thanks for the suggestion Maciej. > > OSSIM sounds very promising (from what I've read so far). Till today I > never managed to get OSSIM running under Ubuntu. I've seen it only under > some win-boxes and partially running under wine. But it's probably an > adventure to compile it properly. > > ___ > 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] execute commands automatically after start of grass
On Fri, Aug 1, 2008 at 2:35 PM, Daniel Victoria <[EMAIL PROTECTED]> wrote: > Why not put a test inside .grass.bashrc to check if you are in the > mapset you want R to run? > Something like: > > if [ $MAPSET = __your_targuet__ ]; do > r & > emacs & > fi Good idea - I think I will go that way. Rainer > > Cheers > Daniel > > On Fri, Aug 1, 2008 at 6:23 AM, Rainer M Krug <[EMAIL PROTECTED]> wrote: >> On Fri, Aug 1, 2008 at 11:16 AM, Jachym Cepicky >> <[EMAIL PROTECTED]> wrote: >>> hi, >>> >>> you can adjust anything in .grass.bashrc file >>> >>> e.g. >>> >>> #!/bin/sh >>> export GRASS_ADDON_PATH=$HOME/usr/grass/ >>> export GRASS_PAGER=/bin/more >> >> Thanks - that looks exactly what I am looking for. >> But is there a way of specifying a certain .grass.bashrc which should be >> used? >> >> The reasoning is that for certain projects I need R and emacs and >> would like to start them automatically, for others not. Obviously, I >> could use a startup script which renames the apropriate file to >> .grass.bashrc, but it would be cleaner to be able to specify it when >> starting grass. >> >> >>> >>> >>> jachym >>> >>> [1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html >>> >>> 2008/8/1 Rainer M Krug <[EMAIL PROTECTED]>: Hi I am using grass in combination with R, wherefore I have to start R (or emacs) after starting grass. Is there any way, to make this automatic, i.e., can I specify a script which is executed inside grass after it is started? In addition, I only would like that to happen when I start grass in a certain mapset and not in other mapsets. Thanks Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Plant Conservation Unit Department of Botany University of Cape Town Rondebosch 7701 South Africa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user >>> >>> >>> >>> -- >>> Jachym Cepicky >>> e-mail: jachym.cepicky gmail com >>> URL: http://les-ejk.cz >>> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub >>> >> >> >> >> -- >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation >> Biology, UCT), Dipl. Phys. (Germany) >> >> Centre of Excellence for Invasion Biology >> Faculty of Science >> Natural Sciences Building >> Private Bag X1 >> University of Stellenbosch >> Matieland 7602 >> South Africa >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Faculty of Science Natural Sciences Building Private Bag X1 University of Stellenbosch Matieland 7602 South Africa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] execute commands automatically after start of grass
Why not put a test inside .grass.bashrc to check if you are in the mapset you want R to run? Something like: if [ $MAPSET = __your_targuet__ ]; do r & emacs & fi Cheers Daniel On Fri, Aug 1, 2008 at 6:23 AM, Rainer M Krug <[EMAIL PROTECTED]> wrote: > On Fri, Aug 1, 2008 at 11:16 AM, Jachym Cepicky > <[EMAIL PROTECTED]> wrote: >> hi, >> >> you can adjust anything in .grass.bashrc file >> >> e.g. >> >> #!/bin/sh >> export GRASS_ADDON_PATH=$HOME/usr/grass/ >> export GRASS_PAGER=/bin/more > > Thanks - that looks exactly what I am looking for. > But is there a way of specifying a certain .grass.bashrc which should be used? > > The reasoning is that for certain projects I need R and emacs and > would like to start them automatically, for others not. Obviously, I > could use a startup script which renames the apropriate file to > .grass.bashrc, but it would be cleaner to be able to specify it when > starting grass. > > >> >> >> jachym >> >> [1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html >> >> 2008/8/1 Rainer M Krug <[EMAIL PROTECTED]>: >>> Hi >>> >>> I am using grass in combination with R, wherefore I have to start R >>> (or emacs) after starting grass. >>> Is there any way, to make this automatic, i.e., can I specify a script >>> which is executed inside grass after it is started? >>> In addition, I only would like that to happen when I start grass in a >>> certain mapset and not in other mapsets. >>> >>> >>> Thanks >>> >>> Rainer >>> >>> -- >>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation >>> Biology, UCT), Dipl. Phys. (Germany) >>> >>> Plant Conservation Unit >>> Department of Botany >>> University of Cape Town >>> Rondebosch 7701 >>> South Africa >>> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> >> -- >> Jachym Cepicky >> e-mail: jachym.cepicky gmail com >> URL: http://les-ejk.cz >> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub >> > > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Faculty of Science > Natural Sciences Building > Private Bag X1 > University of Stellenbosch > Matieland 7602 > South Africa > ___ > 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] Compiling addons from svn repository
On Fri, 2008-08-01 at 13:05 +0300, Nikos Alexandris wrote: > Next you have to point "make" to the GRASS installation directory (not > the source!), something like: > make MODULE_TOPDIR=usr/local/grass-6.4.svn Sorry. Details are important. make MODULE_TOPDIR=/usr/local/grass-6.4.svn > Finally you have to re-run "sudo make install" from within the > GRASS-source directory. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
On Fri, 2008-08-01 at 12:01 +0200, Maciej Sieczka wrote: > Nikos Alexandris pisze: > > how do Open Source Professionals image normalisation for aerial > > photos... let's say 300 photos? I cannot imagine that people sit-down > > and extract psuedoinvariant targets for 300 photos (except they are > > payed a lot for that). > > Nikos, > > Have you looked at OSSIM? Not that I'm sure it provides the tool, but > seems likely. > Thanks for the suggestion Maciej. OSSIM sounds very promising (from what I've read so far). Till today I never managed to get OSSIM running under Ubuntu. I've seen it only under some win-boxes and partially running under wine. But it's probably an adventure to compile it properly. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Compiling addons from svn repository
On Fri, 2008-08-01 at 11:58 +0200, Eduardo corbelle wrote: > Dear all: > > I would like to install an add-on for GRASS 6.3.1 called i.pr that > appears to be available on the svn repository. I never used the svn > repository so I find it a bit challenging (I cannot fully understand > the instructions on > http://www.hpcc.nectec.or.th/grass/download/addons.php). Could anyone > tell me which code should I write at the bash in order to download and > compile the add-on? (any detailed link would do). [...] Assuming you have a working grass installation and you have downloaded the grass-addons, enter the grass-addon directory of you interest (for example if you want to install i.pr): cd /your-path/grass-addons/imagery/i.pr/ Next you have to point "make" to the GRASS installation directory (not the source!), something like: make MODULE_TOPDIR=usr/local/grass-6.4.svn Finally you have to re-run "sudo make install" from within the GRASS-source directory. That should do it. Greets, Nikos P.S. I can't get i.pr working. I've read the help files and the tried the example commands but I always get a Black image when I run i.pr_training. If you have any success could you please post an example? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
Nikos Alexandris pisze: how do Open Source Professionals image normalisation for aerial photos... let's say 300 photos? I cannot imagine that people sit-down and extract psuedoinvariant targets for 300 photos (except they are payed a lot for that). Nikos, Have you looked at OSSIM? Not that I'm sure it provides the tool, but seems likely. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Compiling addons from svn repository
Dear all: I would like to install an add-on for GRASS 6.3.1 called i.pr that appears to be available on the svn repository. I never used the svn repository so I find it a bit challenging (I cannot fully understand the instructions on http://www.hpcc.nectec.or.th/grass/download/addons.php). Could anyone tell me which code should I write at the bash in order to download and compile the add-on? (any detailed link would do). Thank you very much Eduardo Corbelle PS: I'm not sure whether it is relevant, but I'm running grass on Debian Lenny and I have the Subversion client installed. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed speed-up
With the "fast" drainage versions I could reproduce water outlet basins with unsignificant differences. Apart the time saving :-) 2008/8/1 G. Allegri <[EMAIL PROTECTED]>: > Great. Things get better and faster! > I've tried on a not so big region. But it was enough: > > 989861 cells (172286 null cells under MASK, where I have the see) > > It has taken about 55 seconds (I don't have time to set up a > profiling), where I asked for drain and visual outputs creation. > > The stats are (calculated in OO): > > DIFF-VALUES N.PIXELS PERCENTAGE > -7 56 0,0068 > -6 30 0,0037 > -5 32 0,0039 > -4 49 0,0060 > -3 38 0,0046 > -2 180 0,0220 > -1 914 0,1118 > 0 814650 99,6422 > 1 910 0,1113 > 2 229 0,0280 > 3 79 0,0097 > 4 42 0,0051 > 5 21 0,0026 > 6 70 0,0086 > 7 152 0,0186 > 8 22 0,0027 > 9 21 0,0026 > 10 5 0,0006 > 11 15 0,0018 > 12 30 0,0037 > 13 18 0,0022 > 14 3 0,0004 > 15 5 0,0006 > 16 4 0,0005 > > Things has run better then with the previous version, as >99.6% of > values are equal to r.watershed. > > Thanks, a lot, for r.watershed.fast! :-) > Giovanni > > 2008/8/1 Markus Metz <[EMAIL PROTECTED]>: >> Hello list, >> >> there is now a new version of r.watershed.fast where results are even more >> similar to r.watershed. They are still not 100% identical to r.watershed, >> but I can't get it more similar. But it comes with a further speed increase. >> I repeated the test of Moritz with the same commands on GRASS 6.4.svn, >> results are below. >> >> Moritz Lennert wrote: >>> >>> First test in North Carolina demo data set: >>> >>> g.region rast=elevation >>> >>> time r.watershed [EMAIL PROTECTED] accumulation=old_accum >>> drainage=old_dir basin=old_sheds stream=old_streams thresh=500 >>> >>> real19m2.744s >>> user18m41.318s >>> sys 0m1.884s >>> >>> time r.watershed.fast [EMAIL PROTECTED] >>> accumulation=fast_accum drainage=fast_dir basin=fast_sheds >>> stream=fast_streams thresh=500 >>> >>> real0m18.034s >>> user0m17.833s >>> sys 0m0.196s >> >> Absolute times are not really comparable between systems, but relative >> differences in time should be similar. The following numbers are calculated >> with real time. In the test Moritz did, r.watershed took 63x as long as >> r.watershed.fast, i.e. r.watershed.fast needed only 1.6% of the time of >> r.watershed. >> New version: r.watershed took 127x as long as r.watershed.fast, i.e. >> r.watershed.fast needed only 0.8% of the time of r.watershed. >>> >>> Of the 2025000 cells in the map, 1991218 show the same direction, i.e. >>> 98%. Those which have different directions are overwhelmingly low slope >>> cells. >> >> New version: 2004480 cells, i.e. 99% of all cells show the same flow >> direction. >>> >>> 1833907 cells have the same accumulation value, i.e. 90%, but I guess this >>> is to be expected. >> >> New version: 1921510 cells, i.e. 95% of all cells show the same accumulation >> value. >> >> The idea is that a faster r.watershed can also be used for massive grids, >> where GRASS users frequently gave up using r.watershed because it would have >> taken hours or even days. I resampled "elevation" in the North Carolina demo >> data set from 10m to 3m with r.resamp.rst using default values (after the >> GRASS book Section 5.3.3, paragraph "Regularized spline with tension (RST) >> interpolation") to generate a fairly large map and ran the same test on the >> resampled map. >> >> cells in region : 22,500,000 >> >> The results: >> >> Speed: >> r.watershed took 5459x as long as r.watershed.fast, i.e. r.watershed.fast >> needed only 0.02% of the time of r.watershed (here 10h2m55s vs. 1m7s, 10 >> hours versus 1 minute...). >> >> Flow direction differences: >> 22288539 cells, i.e. 99% of all cells show the same flow direction. >> >> Flow accumulation differences: >> 20963653 cells, i.e. 93% of all cells show the same accumulation value. >> >> Memory usage of r.watershed and r.watershed.fast: maximum of about 940MB >> I don't understand why memory usage increases after > Memory> is completed. >> Assuming that there is no longer a time constraint but only a memory >> constraint (although can take some time >> on large maps with a large threshold value), the upper region sizes that >> r.watershed.fast can process in RAM would be *roughly* for >> 1GB RAM: 14,000,000 cells >> 2GB RAM: 38,000,000 cells >> 4GB RAM: 86,000,000 cells >> 8GB RAM: 181,000,000 cells >> after putting 400MB aside for the system and other open applications. >> Estimate based on Linux 64bit. >> >> If you want to repeat and analyse the tests with the North Carolina demo >> data set, the new r.watershed.fast is here >> http://markus.metz.giswork.googlepages.com/r.watershed_fast_version.tar.gz >> and the test script is below. >> >> Regards, >> >>
Re: [GRASS-user] execute commands automatically after start of grass
On Fri, Aug 1, 2008 at 11:16 AM, Jachym Cepicky <[EMAIL PROTECTED]> wrote: > hi, > > you can adjust anything in .grass.bashrc file > > e.g. > > #!/bin/sh > export GRASS_ADDON_PATH=$HOME/usr/grass/ > export GRASS_PAGER=/bin/more Thanks - that looks exactly what I am looking for. But is there a way of specifying a certain .grass.bashrc which should be used? The reasoning is that for certain projects I need R and emacs and would like to start them automatically, for others not. Obviously, I could use a startup script which renames the apropriate file to .grass.bashrc, but it would be cleaner to be able to specify it when starting grass. > > > jachym > > [1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html > > 2008/8/1 Rainer M Krug <[EMAIL PROTECTED]>: >> Hi >> >> I am using grass in combination with R, wherefore I have to start R >> (or emacs) after starting grass. >> Is there any way, to make this automatic, i.e., can I specify a script >> which is executed inside grass after it is started? >> In addition, I only would like that to happen when I start grass in a >> certain mapset and not in other mapsets. >> >> >> Thanks >> >> Rainer >> >> -- >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation >> Biology, UCT), Dipl. Phys. (Germany) >> >> Plant Conservation Unit >> Department of Botany >> University of Cape Town >> Rondebosch 7701 >> South Africa >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Faculty of Science Natural Sciences Building Private Bag X1 University of Stellenbosch Matieland 7602 South Africa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed speed-up
Great. Things get better and faster! I've tried on a not so big region. But it was enough: 989861 cells (172286 null cells under MASK, where I have the see) It has taken about 55 seconds (I don't have time to set up a profiling), where I asked for drain and visual outputs creation. The stats are (calculated in OO): DIFF-VALUES N.PIXELS PERCENTAGE -7 56 0,0068 -6 30 0,0037 -5 32 0,0039 -4 49 0,0060 -3 38 0,0046 -2 180 0,0220 -1 914 0,1118 0 814650 99,6422 1 910 0,1113 2 229 0,0280 3 79 0,0097 4 42 0,0051 5 21 0,0026 6 70 0,0086 7 152 0,0186 8 22 0,0027 9 21 0,0026 10 5 0,0006 11 15 0,0018 12 30 0,0037 13 18 0,0022 14 3 0,0004 15 5 0,0006 16 4 0,0005 Things has run better then with the previous version, as >99.6% of values are equal to r.watershed. Thanks, a lot, for r.watershed.fast! :-) Giovanni 2008/8/1 Markus Metz <[EMAIL PROTECTED]>: > Hello list, > > there is now a new version of r.watershed.fast where results are even more > similar to r.watershed. They are still not 100% identical to r.watershed, > but I can't get it more similar. But it comes with a further speed increase. > I repeated the test of Moritz with the same commands on GRASS 6.4.svn, > results are below. > > Moritz Lennert wrote: >> >> First test in North Carolina demo data set: >> >> g.region rast=elevation >> >> time r.watershed [EMAIL PROTECTED] accumulation=old_accum >> drainage=old_dir basin=old_sheds stream=old_streams thresh=500 >> >> real19m2.744s >> user18m41.318s >> sys 0m1.884s >> >> time r.watershed.fast [EMAIL PROTECTED] >> accumulation=fast_accum drainage=fast_dir basin=fast_sheds >> stream=fast_streams thresh=500 >> >> real0m18.034s >> user0m17.833s >> sys 0m0.196s > > Absolute times are not really comparable between systems, but relative > differences in time should be similar. The following numbers are calculated > with real time. In the test Moritz did, r.watershed took 63x as long as > r.watershed.fast, i.e. r.watershed.fast needed only 1.6% of the time of > r.watershed. > New version: r.watershed took 127x as long as r.watershed.fast, i.e. > r.watershed.fast needed only 0.8% of the time of r.watershed. >> >> Of the 2025000 cells in the map, 1991218 show the same direction, i.e. >> 98%. Those which have different directions are overwhelmingly low slope >> cells. > > New version: 2004480 cells, i.e. 99% of all cells show the same flow > direction. >> >> 1833907 cells have the same accumulation value, i.e. 90%, but I guess this >> is to be expected. > > New version: 1921510 cells, i.e. 95% of all cells show the same accumulation > value. > > The idea is that a faster r.watershed can also be used for massive grids, > where GRASS users frequently gave up using r.watershed because it would have > taken hours or even days. I resampled "elevation" in the North Carolina demo > data set from 10m to 3m with r.resamp.rst using default values (after the > GRASS book Section 5.3.3, paragraph "Regularized spline with tension (RST) > interpolation") to generate a fairly large map and ran the same test on the > resampled map. > > cells in region : 22,500,000 > > The results: > > Speed: > r.watershed took 5459x as long as r.watershed.fast, i.e. r.watershed.fast > needed only 0.02% of the time of r.watershed (here 10h2m55s vs. 1m7s, 10 > hours versus 1 minute...). > > Flow direction differences: > 22288539 cells, i.e. 99% of all cells show the same flow direction. > > Flow accumulation differences: > 20963653 cells, i.e. 93% of all cells show the same accumulation value. > > Memory usage of r.watershed and r.watershed.fast: maximum of about 940MB > I don't understand why memory usage increases after Memory> is completed. > Assuming that there is no longer a time constraint but only a memory > constraint (although can take some time > on large maps with a large threshold value), the upper region sizes that > r.watershed.fast can process in RAM would be *roughly* for > 1GB RAM: 14,000,000 cells > 2GB RAM: 38,000,000 cells > 4GB RAM: 86,000,000 cells > 8GB RAM: 181,000,000 cells > after putting 400MB aside for the system and other open applications. > Estimate based on Linux 64bit. > > If you want to repeat and analyse the tests with the North Carolina demo > data set, the new r.watershed.fast is here > http://markus.metz.giswork.googlepages.com/r.watershed_fast_version.tar.gz > and the test script is below. > > Regards, > > Markus > > > test script: > g.region rast=elevation > time r.watershed [EMAIL PROTECTED] accumulation=nc_accum_old > drainage=nc_dir_old basin=nc_sheds_old stream=nc_streams_old thresh=500 > time r.watershed.fast [EMAIL PROTECTED] > accumulation=nc_accum_fast drainage=nc_dir_fast basin=nc_sheds_fast > stream=nc_streams_fast thresh=500 > r.mapc
Re: [GRASS-user] execute commands automatically after start of grass
hi, you can adjust anything in .grass.bashrc file e.g. #!/bin/sh export GRASS_ADDON_PATH=$HOME/usr/grass/ export GRASS_PAGER=/bin/more jachym [1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html 2008/8/1 Rainer M Krug <[EMAIL PROTECTED]>: > Hi > > I am using grass in combination with R, wherefore I have to start R > (or emacs) after starting grass. > Is there any way, to make this automatic, i.e., can I specify a script > which is executed inside grass after it is started? > In addition, I only would like that to happen when I start grass in a > certain mapset and not in other mapsets. > > > Thanks > > Rainer > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > > Plant Conservation Unit > Department of Botany > University of Cape Town > Rondebosch 7701 > South Africa > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] execute commands automatically after start of grass
Hi I am using grass in combination with R, wherefore I have to start R (or emacs) after starting grass. Is there any way, to make this automatic, i.e., can I specify a script which is executed inside grass after it is started? In addition, I only would like that to happen when I start grass in a certain mapset and not in other mapsets. Thanks Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Plant Conservation Unit Department of Botany University of Cape Town Rondebosch 7701 South Africa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed speed-up
Hello list,
there is now a new version of r.watershed.fast where results are even
more similar to r.watershed. They are still not 100% identical to
r.watershed, but I can't get it more similar. But it comes with a
further speed increase. I repeated the test of Moritz with the same
commands on GRASS 6.4.svn, results are below.
Moritz Lennert wrote:
First test in North Carolina demo data set:
g.region rast=elevation
time r.watershed [EMAIL PROTECTED] accumulation=old_accum
drainage=old_dir basin=old_sheds stream=old_streams thresh=500
real19m2.744s
user18m41.318s
sys 0m1.884s
time r.watershed.fast [EMAIL PROTECTED]
accumulation=fast_accum drainage=fast_dir basin=fast_sheds
stream=fast_streams thresh=500
real0m18.034s
user0m17.833s
sys 0m0.196s
Absolute times are not really comparable between systems, but relative
differences in time should be similar. The following numbers are
calculated with real time. In the test Moritz did, r.watershed took 63x
as long as r.watershed.fast, i.e. r.watershed.fast needed only 1.6% of
the time of r.watershed.
New version: r.watershed took 127x as long as r.watershed.fast, i.e.
r.watershed.fast needed only 0.8% of the time of r.watershed.
Of the 2025000 cells in the map, 1991218 show the same direction, i.e.
98%. Those which have different directions are overwhelmingly low
slope cells.
New version: 2004480 cells, i.e. 99% of all cells show the same flow
direction.
1833907 cells have the same accumulation value, i.e. 90%, but I guess
this is to be expected.
New version: 1921510 cells, i.e. 95% of all cells show the same
accumulation value.
The idea is that a faster r.watershed can also be used for massive
grids, where GRASS users frequently gave up using r.watershed because it
would have taken hours or even days. I resampled "elevation" in the
North Carolina demo data set from 10m to 3m with r.resamp.rst using
default values (after the GRASS book Section 5.3.3, paragraph
"Regularized spline with tension (RST) interpolation") to generate a
fairly large map and ran the same test on the resampled map.
cells in region : 22,500,000
The results:
Speed:
r.watershed took 5459x as long as r.watershed.fast, i.e.
r.watershed.fast needed only 0.02% of the time of r.watershed (here
10h2m55s vs. 1m7s, 10 hours versus 1 minute...).
Flow direction differences:
22288539 cells, i.e. 99% of all cells show the same flow direction.
Flow accumulation differences:
20963653 cells, i.e. 93% of all cells show the same accumulation value.
Memory usage of r.watershed and r.watershed.fast: maximum of about 940MB
I don't understand why memory usage increases after Initiating Memory> is completed.
Assuming that there is no longer a time constraint but only a memory
constraint (although can take some
time on large maps with a large threshold value), the upper region sizes
that r.watershed.fast can process in RAM would be *roughly* for
1GB RAM: 14,000,000 cells
2GB RAM: 38,000,000 cells
4GB RAM: 86,000,000 cells
8GB RAM: 181,000,000 cells
after putting 400MB aside for the system and other open applications.
Estimate based on Linux 64bit.
If you want to repeat and analyse the tests with the North Carolina demo
data set, the new r.watershed.fast is here
http://markus.metz.giswork.googlepages.com/r.watershed_fast_version.tar.gz
and the test script is below.
Regards,
Markus
test script:
g.region rast=elevation
time r.watershed [EMAIL PROTECTED] accumulation=nc_accum_old
drainage=nc_dir_old basin=nc_sheds_old stream=nc_streams_old thresh=500
time r.watershed.fast [EMAIL PROTECTED]
accumulation=nc_accum_fast drainage=nc_dir_fast basin=nc_sheds_fast
stream=nc_streams_fast thresh=500
r.mapcalc nc_dir_dif='if(("nc_dir_old" - "nc_dir_fast" != 0),1,0)'
r.mapcalc nc_accum_dif='if(("nc_accum_old" - "nc_accum_fast" != 0),1,0)'
r.stats -c [EMAIL PROTECTED]
r.stats -c [EMAIL PROTECTED]
r.resamp.rst [EMAIL PROTECTED] ew_res=3 ns_res=3
elev=elevation_rst overlap=3 zmult=1.0 tension=40.
g.region rast=elevation_rst
time r.watershed [EMAIL PROTECTED]
accumulation=nc_rst_accum_old drainage=nc_rst_dir_old
basin=nc_rst_sheds_old stream=nc_rst_streams_old thresh=500
time r.watershed.fast [EMAIL PROTECTED]
accumulation=nc_rst_accum_fast drainage=nc_rst_dir_fast
basin=nc_rst_sheds_fast stream=nc_rst_streams_fast thresh=500
r.mapcalc nc_rst_dir_dif='if(("nc_rst_dir_old" - "nc_rst_dir_fast" !=
0),1,0)'
r.mapcalc nc_rst_accum_dif='if(("nc_rst_accum_old" - "nc_rst_accum_fast"
!= 0),1,0)'
r.stats -c [EMAIL PROTECTED]
r.stats -c [EMAIL PROTECTED]
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
On 31/07/08 20:39, Nikos Alexandris wrote: Any Open Source alternatives for image segmentation? SAGA GIS has some segmentation algorithms included: http://www.saga-gis.uni-goettingen.de/html/index.php Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] importing raster using r.in. *
[Please post usage questions to grass-user.] On 01/08/08 07:43, aschley nod wrote: i'm a beginner in GRASS. I have read in the tutorial that r.in.* is the command to import a raster.So, i tried the following command: r.in.tiff input=phil.tiff output = samplephil and this thing appeared... bash: r.in.tiff: command not found what am i supposed to do? i'm using grass6.3 hope someone can help me. Use r.in.gdal. As a beginner, it would be useful for you to look at the 'Introduction' pages linked to from http://grass.osgeo.org/grass63/manuals/html63_user/index.html Moritz Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
