[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
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
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 SECTION 1a: Initiating Memory is completed. Assuming that there is no longer a time constraint but only a memory constraint (although SECTION 4: Watershed Determination 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
[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] 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
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 SECTION 1a: Initiating Memory is completed. Assuming that there is no longer a time constraint but only a memory constraint (although SECTION 4: Watershed Determination 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
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
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 SECTION 1a: Initiating Memory is completed. Assuming that there is no longer a time constraint but only a memory constraint (although SECTION 4: Watershed Determination 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
[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] 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
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] 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: pseudo-code here - can't remember bash sintax 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
[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
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] 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
[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] 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 layer resp. r.info -g layer. 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
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] 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] 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
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] 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] 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
