Re: [GRASS-user] interesting article on TIN generation
Dylan, As I spend a couple of days computing a huge lidar dataset (first split the original file in 145 pieces ! then performing a loop with v.surf.rst, and rearrange data in a single raster), it is of great interest for us. Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... Le lundi 22 septembre 2008 à 15:53 -0700, Dylan Beaudette a écrit : Thought this would be of interest: http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf Cheers, Dylan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Vincent Bain wrote: As I spend a couple of days computing a huge lidar dataset (first split the original file in 145 pieces ! then performing a loop with v.surf.rst, and rearrange data in a single raster), it is of great interest for us. I still look for a nice method to paste together overlapping splines cleanly. rant IM(V)HO, the surface created by v.surf.rst splines will be an order of magnitude(s) closer to reality and is really worth the extra effort. I haven't run any analysis to back that up quantitatively, perhaps Dylan already has? ;) (well maybe not, but I wouldn't be surprised) /rant boring anecdote In years long past I did some 3D density modelling in which case I could for a test case solve the answer analytically to test my iterative solution. After the iterative solution had been running for a while I added some instrumentation to see what cell resolution and time it would take to get within the required % of the known answer using the linear interpolation method. It turned out that my process would finish in about 126 years using the Sun workstation of the day. I canceled the job and rewrote it using 3D trapezoids instead of Q-bert blocks. It finished in 5 minutes. Ok, for that the solution /was/ a form of TIN, but I think the idea scales between linear and cubic interpolations. /boring anecdote back to rant IM(V)HO the fact that TINs are used so much to make raster surfaces is an artifact kludge from a history of other well known GIS which was historically strong with vector data but weak with raster data (ie the opposite to GRASS's history). IM(V)H estimation, among the many hundreds of GRASS modules and 25 years, TINs conspicuously never made an appearance in GRASS for the simple reason that there was no need for such a poor solution when much better ones were already available. In the face of a strong raster engine things like TINs are perhaps handled more efficiently and directly dealt with by the display drivers. /rant If speed is a real limiting factor I'd suggest trying v.surf.idw(2), or perhaps r.surf.nnbathy*. Maybe they hit the time vs. results tradeoff sweet spot better. Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... I could have sworn there was a TIN module on the wiki addons page, but don't see it now. Maybe it was lurking in the R-interface tutorials or somewhere? (The grass wiki as-setup doesn't search for 3 letter words, which is a bit of a problem) 3c, Hamish [*] Is there any thoughts on moving r.surf.nnbathy into the main source? It requires an external dependency to use, but so do many other scripts. To me it's a valuable addition to the available quiver of interpolation methods; a nice compromise between IDW and splines. Before doing that I think to change it to be v.surf.nnbathy (its first step is r.to.vect). ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] vector operations based on rasters
Tim Michelsen wrote: I have calculated raster file based on a DEM with some r.mapcalc commands. As a result, my raster file with the areas of interest is smaller than the whole region. How do I intersect the landcover vector of the whole region to get a new landcover vector with only those polygons contained within the areas of interest of the raster? Basically, I'd like to run v.extract/v.overlay not on a vector-to-vector basis but on a vector-to-raster basis. g.region rast=dem_name v.in.region dem_box then v.overlay or v.select, depending on if you want to want to clip touching vector areas at the bound or not. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Le mardi 23 septembre 2008 à 01:17 -0700, Hamish a écrit : I still look for a nice method to paste together overlapping splines cleanly. Maybe first generating /sufficiently/ overlapping tiles, then adjust adjacent ones in the middle of the overlap (ok, not very clean) IM(V)HO the fact that TINs are used so much to make raster surfaces is an artifact kludge from a history of other well known GIS which was historically strong with vector data but weak with raster data Yes, it's hard to ged rid of some old /educational/ reflexes. I agree ! but anyway, TINGRID was very useful. If speed is a real limiting factor I'd suggest trying v.surf.idw(2), or perhaps r.surf.nnbathy*. Very useful module if one needs to generate a non-interpolated surface, fitting exactly a given set of points. Could it become a default command in Grass ? Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... I could have sworn there was a TIN module on the wiki addons page, but don't see it now. Maybe it was lurking in the R-interface tutorials or somewhere? (The grass wiki as-setup doesn't search for 3 letter words, which is a bit of a problem) Maybe you confuse with the TIN how-to ? using Paraview and Meshlab http://grass.osgeo.org/wiki/HOWTO_create_3D_TIN 3c, Hamish [*] Is there any thoughts on moving r.surf.nnbathy into the main source? It requires an external dependency to use, but so do many other scripts. To me it's a valuable addition to the available quiver of interpolation methods; a nice compromise between IDW and splines. Before doing that I think to change it to be v.surf.nnbathy (its first step is r.to.vect). ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Second try, run grass scripts as batch process in Windows
Dear All, Can anyone give me a clue on how to run GRASS scripts as a batch process on Windows (Native Windows version, 6.3)? Thank's, Kris -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Sorry I forgot the PS [*] Is there any thoughts on moving r.surf.nnbathy into the main source? It requires an external dependency to use, but so do many other scripts. To me it's a valuable addition to the available quiver of interpolation methods; a nice compromise between IDW and splines. Before doing that I think to change it to be v.surf.nnbathy (its first step is r.to.vect). Yes indeed it would be faster when starting from a set of vector points. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Second try, run grass scripts as batch process in Windows
On 23/09/08 10:51, Kris Nackaerts wrote: Dear All, Can anyone give me a clue on how to run GRASS scripts as a batch process on Windows (Native Windows version, 6.3)? You have three options: - Run a *nix shell (e.g. bash) script in msys. This means launching 'command line GRASS' in msys (IIRC the current installer creates a shortcut for this in the GRASS menu). - Write your script as a cmd.exe script. - Write your script in a cross-platform language such as Python. In time, the aim is to move all scripting to Python so as to avoid these platform-related issues in the future. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] nnbathy
Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? Cheers John ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
Same questions from me. I looked for it a week ago... 2008/9/23 John Stevenson [EMAIL PROTECTED]: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? Cheers 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] nnbathy
Given your system, don't know if it can help, but the Natural Neighbours interpolation library is available here : http://packages.ubuntu.com/hardy/libs/libcsiro0 Le mardi 23 septembre 2008 à 12:18 +0100, John Stevenson a écrit : Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? Cheers 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] Second try, run grass scripts as batch process in Windows
Moritz Lennert wrote: Can anyone give me a clue on how to run GRASS scripts as a batch process on Windows (Native Windows version, 6.3)? You have three options: - Run a *nix shell (e.g. bash) script in msys. This means launching 'command line GRASS' in msys (IIRC the current installer creates a shortcut for this in the GRASS menu). - Write your script as a cmd.exe script. - Write your script in a cross-platform language such as Python. For batch jobs, you need to create a grassrc file containing settings for GISDBASE, LOCATION_NAME and MAPSET, and set certain environment variables. The main ones are: PATH - must include %GISBASE%/bin and %GISBASE%/lib GISBASE - the directory where GRASS is installed. GISRC - the pathname of a grassrc file GRASS_SH - the path to a Unix-compatible Bourne shell (only required if you need to run shell scripts) -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
On 23/09/08 13:18, John Stevenson wrote: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? http://web.archive.org/web/20080203105504/http://www.marine.csiro.au/~sak007/ I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Attempt to export (r.out.gdal) produces sometimes an error and sometimes not
r.info composite_b123 -tr min=0 max=32767 datatype=CELL [Raster MASK present] 1st attempt to export: r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif Exporting to GDAL data type: UInt16 Segmentation fault [Raster MASK present] 2nd attempt to export without any change: r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif Exporting to GDAL data type: UInt16 Warning 1: Lost metadata writing to GeoTIFF ... too large to fit in tag. 100% WARNING: Input raster map constains cells with NULL-value (no-data). The value -32768 was used to represent no-data values in the input map.You can specify nodata value by nodata parameter. Warning 1: Lost metadata writing to GeoTIFF ... too large to fit in tag. r.out.gdal complete. [Raster MASK present] Shouldn't the same error message (from the 1st attempt) remain? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
I could use the one from the Ubuntu repositories. Thanks 2008/9/23 Moritz Lennert [EMAIL PROTECTED]: On 23/09/08 13:49, Moritz Lennert wrote: On 23/09/08 13:18, John Stevenson wrote: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? http://web.archive.org/web/20080203105504/http://www.marine.csiro.au/~sak007/ I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ As a follow-up: I have sent a mail to Pavel Sakov to find out where the code is available now. Moritz ___ 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] nnbathy
On 23/09/08 13:49, Moritz Lennert wrote: On 23/09/08 13:18, John Stevenson wrote: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? http://web.archive.org/web/20080203105504/http://www.marine.csiro.au/~sak007/ I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ As a follow-up: I have sent a mail to Pavel Sakov to find out where the code is available now. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
You're right Moritz. I thought it contained also the executable... 2008/9/23 Moritz Lennert [EMAIL PROTECTED]: On 23/09/08 14:07, G. Allegri wrote: I could use the one from the Ubuntu repositories. Just out of curiosity: how does this work ? IIUC, the Ubuntu library version does not contain the nnbathy executable which r.surf.nnbathy calls, but only a C-library. How do you use this for the script ? Moritz Thanks 2008/9/23 Moritz Lennert [EMAIL PROTECTED]: On 23/09/08 13:49, Moritz Lennert wrote: On 23/09/08 13:18, John Stevenson wrote: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? http://web.archive.org/web/20080203105504/http://www.marine.csiro.au/~sak007/ I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ As a follow-up: I have sent a mail to Pavel Sakov to find out where the code is available now. Moritz ___ 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] Second try, run grass scripts as batch process in Windows
On 23/09/08 14:35, Kris Nackaerts wrote: Thank's, I like the Python option. I'm using Python now quite a lot for some processng, and also in pl/python in postGIS. This would fit great. But, the documentation keeps confusing me, I read: Sample script for raster access (use within GRASS, Spearfish session): Why is there use within GRASS. I assume when importing in python, I do not need to be inside GRASS? A series of environment variables need to be set for GRASS modules to work. Starting GRASS means mostly that, i.e. setting these variables. As Glynn mentioned, you can set them by hand. See http://grass.osgeo.org/wiki/GRASS_and_Shell for some instructions. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
Sorry for the wrong way, and thank you Morritz for contacting P. Sakov ! VB Le mardi 23 septembre 2008 à 14:50 +0200, G. Allegri a écrit : You're right Moritz. I thought it contained also the executable... 2008/9/23 Moritz Lennert [EMAIL PROTECTED]: On 23/09/08 14:07, G. Allegri wrote: I could use the one from the Ubuntu repositories. Just out of curiosity: how does this work ? IIUC, the Ubuntu library version does not contain the nnbathy executable which r.surf.nnbathy calls, but only a C-library. How do you use this for the script ? Moritz Thanks 2008/9/23 Moritz Lennert [EMAIL PROTECTED]: On 23/09/08 13:49, Moritz Lennert wrote: On 23/09/08 13:18, John Stevenson wrote: Hi, I am keen to try r.surf.nnbathy, but I cannot find the nn libraries online. The link given in the instructions: http://www.marine.csiro.au/~sak007 is dead. Does anyone know where I can get them from now? http://web.archive.org/web/20080203105504/http://www.marine.csiro.au/~sak007/ I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ As a follow-up: I have sent a mail to Pavel Sakov to find out where the code is available now. Moritz ___ 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] script by bash to Python
Martin Landa-2 wrote: Hi, 2008/7/5 Gabriele N. [EMAIL PROTECTED]: I use grass63 with wxpython and I do not know how to use some scripts that I have in bash. The graphical interface opens but when I try to launch the script I get the following error: GRASS 6.3.0 (gb2):~ v.topo_5 $ v.topo_5 percorso=/home/gab/prova.shp nome_vett=foglio num=3 campo=foglio Traceback (most recent call last): File /usr/lib/grass/etc/wxpython/gui_modules/menuform.py, line 763, in OnRun self.goutput.RunCmd(cmd) File /usr/lib/grass/etc/wxpython/gui_modules/goutput.py, line 209, in RunCmd generalCmd = subprocess.Popen(cmdlist, NameError: global name 'subprocess' is not defined If I run the script with grass -tcltk works well. Upgrading to grass64 (devbr6) should fix it. Martin I speak again of this post. With grass64 svn the situation has improved. Some scripts in bash run well and others do not. But I do not understand what are the differences between a script that works and a script that does not work. I do not see the differences. Thanks -- View this message in context: http://www.nabble.com/script-by-bash-to-Python-tp18292175p19630269.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
On Tue, Sep 23, 2008 at 6:12 AM, Moritz Lennert [EMAIL PROTECTED] wrote: On 23/09/08 14:06, Moritz Lennert wrote: On 23/09/08 13:49, Moritz Lennert wrote: I have also put it on my machine, in case the above link doesn't work anymore: http://geog-pc40.ulb.ac.be/grass/nnbathy/ As a follow-up: I have sent a mail to Pavel Sakov to find out where the code is available now. Pavel sent me the code. It is available at above address. We will see whether he will set up a new web site, or whether we will integrate the code into the Add-Ons SVN. Moritz I have not seen the original code / license, but would it be possible to directly integrate the code into GRASS? This would remove the dependency of an external nnbathy library. Cheers, Dylan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
On Mon, Sep 22, 2008 at 11:10 PM, Vincent Bain [EMAIL PROTECTED] wrote: Dylan, As I spend a couple of days computing a huge lidar dataset (first split the original file in 145 pieces ! then performing a loop with v.surf.rst, and rearrange data in a single raster), it is of great interest for us. Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... I have not looked over the license, but it would probably be beyond what my time/skill level permits. Have you considered using r.in.xyz (pre-filtering module) for your massive lidar dataset? Also, by submitting that article to the list, I wasn't advocating the use of TINs over grids-- I just thought it was interesting. I still think that for most modeling operations, gridded data are the simplest to use / understand. Cheers, Dylan Le lundi 22 septembre 2008 à 15:53 -0700, Dylan Beaudette a écrit : Thought this would be of interest: http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf Cheers, Dylan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nnbathy
I have not seen the original code / license, but would it be possible to directly integrate the code into GRASS? This would remove the dependency of an external nnbathy library. This would be great. cheers Carlos -- +---+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +---+ _ Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive. --The winning entry in a What were HAL's first words contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
On Tue, Sep 23, 2008 at 1:17 AM, Hamish [EMAIL PROTECTED] wrote: Vincent Bain wrote: As I spend a couple of days computing a huge lidar dataset (first split the original file in 145 pieces ! then performing a loop with v.surf.rst, and rearrange data in a single raster), it is of great interest for us. I still look for a nice method to paste together overlapping splines cleanly. Indeed-- the segmentation artifacts are a bit annoying, although I cannot offer any alternatives other than increasing the segmax parameter. rant IM(V)HO, the surface created by v.surf.rst splines will be an order of magnitude(s) closer to reality and is really worth the extra effort. I haven't run any analysis to back that up quantitatively, perhaps Dylan already has? ;) (well maybe not, but I wouldn't be surprised) /rant Haven't done that analysis yet, but it would be fun to try :) . I will be at AGU with Helena this December, maybe we can get some ideas together before then and I will present them to her at the conference. I see that there are several ideas / problems / etc. posted on the wiki: http://grass.osgeo.org/wiki/RST_Spline_Surfaces boring anecdote In years long past I did some 3D density modelling in which case I could for a test case solve the answer analytically to test my iterative solution. After the iterative solution had been running for a while I added some instrumentation to see what cell resolution and time it would take to get within the required % of the known answer using the linear interpolation method. It turned out that my process would finish in about 126 years using the Sun workstation of the day. I canceled the job and rewrote it using 3D trapezoids instead of Q-bert blocks. It finished in 5 minutes. Ok, for that the solution /was/ a form of TIN, but I think the idea scales between linear and cubic interpolations. /boring anecdote interesting... back to rant IM(V)HO the fact that TINs are used so much to make raster surfaces is an artifact kludge from a history of other well known GIS which was historically strong with vector data but weak with raster data (ie the opposite to GRASS's history). IM(V)H estimation, among the many hundreds of GRASS modules and 25 years, TINs conspicuously never made an appearance in GRASS for the simple reason that there was no need for such a poor solution when much better ones were already available. In the face of a strong raster engine things like TINs are perhaps handled more efficiently and directly dealt with by the display drivers. /rant Again, I tend to feel that same way-- unless you are working with some kind of hardware-accelerated triangle rendering device (i.e. OpenGL interface to video card) to *display* a surface in real-time, TINs seem like overkill. However, the TIN data structure is appealing when you want to store more information where there is more local variation: i.e. rugged terrain gets more triangles/area than a valley floor would get. Perhaps a well-designed, quadtree-indexed (or tiled?) raster data model could function in a similar fashion...? If speed is a real limiting factor I'd suggest trying v.surf.idw(2), or perhaps r.surf.nnbathy*. Maybe they hit the time vs. results tradeoff sweet spot better. We really should get the nnbathy code / algorithm into a standard GRASS module. For quick and dirty interpolation / large areas it is an ideal approach. Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... I could have sworn there was a TIN module on the wiki addons page, but don't see it now. Maybe it was lurking in the R-interface tutorials or somewhere? (The grass wiki as-setup doesn't search for 3 letter words, which is a bit of a problem) 3c, Hamish [*] Is there any thoughts on moving r.surf.nnbathy into the main source? It requires an external dependency to use, but so do many other scripts. To me it's a valuable addition to the available quiver of interpolation methods; a nice compromise between IDW and splines. Before doing that I think to change it to be v.surf.nnbathy (its first step is r.to.vect). +1 on this idea. Just need to look over the licensing / or find an algorithm to stuff into a new module. Cheers, Dylan PS: just back from the southern hemisphere (Rarotonga) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Attempt to export (r.out.gdal) produces sometimes an error and sometimes not
Nikos Alexandris wrote: 1st attempt to export: r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif Exporting to GDAL data type: UInt16 Segmentation fault Shouldn't the same error message (from the 1st attempt) remain? It appears that there is a memory corruption bug somewhere, either in r.out.gdal, the GRASS libraries, the GDAL library, or a library which it uses. The consequences of a memory corruption bug often depend upon the exact memory layout, or even the exact contents of uninitialised memory. Sometimes it will cause problems, sometimes it won't. It doesn't help that such bugs often fail to manifest if the program is run under a debugger (colloquially referred to as a Heisenbug, in reference to the quantum mechanics principle that simply observing a system can change its behaviour). -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Attempt to export (r.out.gdal) produces sometimes an error and sometimes not
On Tue, 2008-09-23 at 19:55 +0100, Glynn Clements wrote: Nikos Alexandris wrote: 1st attempt to export: r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif Exporting to GDAL data type: UInt16 Segmentation fault Shouldn't the same error message (from the 1st attempt) remain? It appears that there is a memory corruption bug somewhere, either in r.out.gdal, the GRASS libraries, the GDAL library, or a library which it uses. The consequences of a memory corruption bug often depend upon the exact memory layout, or even the exact contents of uninitialised memory. Sometimes it will cause problems, sometimes it won't. It doesn't help that such bugs often fail to manifest if the program is run under a debugger (colloquially referred to as a Heisenbug, in reference to the quantum mechanics principle that simply observing a system can change its behaviour). The funny is that the different results replace each other after each attempt (I think I tried more than 6 times). One error and one success, one error and one success... ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] script by bash to Python
Gabriele N. wrote: I use grass63 with wxpython and I do not know how to use some scripts that I have in bash. The graphical interface opens but when I try to launch the script I get the following error: GRASS 6.3.0 (gb2):~ v.topo_5 $ v.topo_5 percorso=/home/gab/prova.shp nome_vett=foglio num=3 campo=foglio Traceback (most recent call last): File /usr/lib/grass/etc/wxpython/gui_modules/menuform.py, line 763, in OnRun self.goutput.RunCmd(cmd) File /usr/lib/grass/etc/wxpython/gui_modules/goutput.py, line 209, in RunCmd generalCmd = subprocess.Popen(cmdlist, NameError: global name 'subprocess' is not defined If I run the script with grass -tcltk works well. Upgrading to grass64 (devbr6) should fix it. I speak again of this post. With grass64 svn the situation has improved. Some scripts in bash run well and others do not. But I do not understand what are the differences between a script that works and a script that does not work. I do not see the differences. The above error is due to a bug in 6.3.0. The bug is only triggered when running a command which isn't recognised as a GRASS command. Recognised commands are those corresponding to files in the bin, scripts and etc/gui/scripts directories, with any .exe or .bat extension removed. It's also possible that individual scripts have bugs which are specific to Windows. GRASS probably doesn't get a fraction of the testing on Windows that it does on Linux and MacOSX. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Precipitation color table?
hi, anyone having a nice precipitation color table (e.g., range from 0mm to 2000mm)? I would like to nicely visualize data from the Global Precipitation Climatology Project (GPCP, [1]): ftp://rsd.gsfc.nasa.gov/pub/1dd/ Could be a nice addon for r.colors. thanks, Markus [1] details ftp://rsd.gsfc.nasa.gov/pub/1dd/1dd.summary ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass gis
Sir I have successfully installed GRASS GIS from the link http://grass.osgeo.org/grass63/binary/mswindows/; software in my PC. I is installed in c:\ GRASS folder. I have installed Spearfish and northDakoda data inGIS DataBase folder. Now I wonder how can I start my learning.Would you please give me advice on a way to start learning the soft systematically and effectively. My heartiest gratitude for your kind help. Sincerely Yours Md. Zahid Parvez M.S.C student Bangladesh Engineering University(B.U.E.T) Dhaka,Bangladesh ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass gis.
Sir I have successfully installed GRASS GIS software in my PC from the link http://grass.osgeo.org/grass63/binary/mswindows/;. I installed in c:\ GRASS folder. I have installed Spearfish and northDakoda data in GIS DataBase folder. Now I wonder how can I start my learning.Would you please give me advice on a way to start learning the soft systematically and effectively. My heartiest gratitude for your kind help. Sincerely Yours Md. Zahid Parvez M.S.C student Bangladesh Engineering University(B.U.E.T) Dhaka,Bangladesh ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass gis
On Wed, 2008-09-24 at 02:26 +0600, Zahid Parvez wrote: Sir I have successfully installed GRASS GIS from the link http://grass.osgeo.org/grass63/binary/mswindows/; software in my PC. I is installed in c:\ GRASS folder. I have installed Spearfish and northDakoda data inGIS DataBase folder. Now I wonder how can I start my learning.Would you please give me advice on a way to start learning the soft systematically and effectively. My heartiest gratitude for your kind help. Sincerely Yours Md. Zahid Parvez M.S.C student Bangladesh Engineering University(B.U.E.T) Dhaka,Bangladesh Hi Zahid. First take some time reading http://grass.osgeo.org/intro/firsttime.php in the official GRASS-GIS web page. Then try to play around with the data you already have or take a look at http://grass.osgeo.org/gdp/tutorials.php where several tutorials give you a starting point. A nice introduction to GRASS' structure can be found in the GRASS manual http://grass.osgeo.org/grass64/manuals/html64_user/helptext.html. You can learn a lot about what you can do with GRASS by reading (again in the manual) the raster processing and vector processing sections: http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Post in the list if you have any kind of difficulties. But it's a good idea to search for an answer that has been already given in this lists archive (look here for links http://grass.osgeo.org/community/support.php). Hope you like the GRASS-GIS experience. Greetings, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Linking error in photo.2image
Hamish wrote: Craig Leat: When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image I get a linking error as follows: /usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable R_386_32 relocation against symbol `line' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make: *** [/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image] Error 1 Hi, I've had this same error during make of grass6.4 snapshot_2008_09_20 I have gdal-1.5.2 and Linux version 2.6.21.5-smp (gcc version 4.1.2) on Slackware 12.0 The error message: cd /space/grass-6.3/grass-6.4.svn_src_snapshot_2008_09_20/imagery/i.ortho.photo/photo.2image make ... /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x880): unresolvable R_386_32 relocation against symbol `line' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make: *** [/space/grass-6.3/grass-6.4.svn_src_snapshot_2008_09_20/dist.i686-pc-linux-gnu/etc/photo.2image] Error 1 Workaround: I simply added -fPIC to CFLAGS and CXXFLAGS for ./configure of grass 6.4.svn_src_snapshot_2008_09_20. Then make is OK with these flags: CFLAGS=-march=prescott -O2 -pipe -fomit-frame-pointer -fPIC CXXFLAGS=-march=prescott -O2 -pipe -fomit-frame-pointer -fPIC Don't know yet if this introduces any unexpected problems elsewhere. Cheers, Peter -- View this message in context: http://www.nabble.com/Linking-error-in-photo.2image-tp19345829p19637645.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] script by bash to Python
Hy Glynn. Ah ... I work on ubuntu 8.04. But what could be the commands in the script that GRASS not 'recognize'? Compared to version 63 with the 64 now run more scripts (always bash). All the scripts still work well in tcltk. ? Thanks Gabriele Glynn Clements wrote: Gabriele N. wrote: I use grass63 with wxpython and I do not know how to use some scripts that I have in bash. The graphical interface opens but when I try to launch the script I get the following error: GRASS 6.3.0 (gb2):~ v.topo_5 $ v.topo_5 percorso=/home/gab/prova.shp nome_vett=foglio num=3 campo=foglio Traceback (most recent call last): File /usr/lib/grass/etc/wxpython/gui_modules/menuform.py, line 763, in OnRun self.goutput.RunCmd(cmd) File /usr/lib/grass/etc/wxpython/gui_modules/goutput.py, line 209, in RunCmd generalCmd = subprocess.Popen(cmdlist, NameError: global name 'subprocess' is not defined If I run the script with grass -tcltk works well. Upgrading to grass64 (devbr6) should fix it. I speak again of this post. With grass64 svn the situation has improved. Some scripts in bash run well and others do not. But I do not understand what are the differences between a script that works and a script that does not work. I do not see the differences. The above error is due to a bug in 6.3.0. The bug is only triggered when running a command which isn't recognised as a GRASS command. Recognised commands are those corresponding to files in the bin, scripts and etc/gui/scripts directories, with any .exe or .bat extension removed. It's also possible that individual scripts have bugs which are specific to Windows. GRASS probably doesn't get a fraction of the testing on Windows that it does on Linux and MacOSX. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://www.nabble.com/script-by-bash-to-Python-tp18292175p19637676.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Precipitation color table?
Dear Markus, I just ran into this page http://geography.uoregon.edu/datagraphics/color_scales.htm that includes, among others, precipitation color tables. I don't know if that can be useful. The page of this Lab also provides an interesting paper titled End of the Rainbow which elaborates on why one should not use continuously varying color schemes (and absolutely no rainbow color table). The way to go seems to be banded color schemes -- a color scheme with equally sized bands of constant color [1]. As I side note I was wondering how to draw such a color scheme (i.e. with equally sized bands of constant color) in GRASS. Kind regards, Luigi [1] Borland D, Taylor II RM (2007) Rainbow color map (still) considered harmful. IEEE Computer Graphics and Applications, 27, 14-17. From: Markus Neteler [EMAIL PROTECTED] Subject: [GRASS-user] Precipitation color table? To: GRASS user list grass-user@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 hi, anyone having a nice precipitation color table (e.g., range from 0mm to 2000mm)? I would like to nicely visualize data from the Global Precipitation Climatology Project (GPCP, [1]): ftp://rsd.gsfc.nasa.gov/pub/1dd/ Could be a nice addon for r.colors. thanks, Markus [1] details ftp://rsd.gsfc.nasa.gov/pub/1dd/1dd.summary ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass gis.
Probably your best bet is OPEN SOURCE GIS: A GRASS GIS Approach - Markus and Helena's book. Cheers, Alex On Wed, 2008-09-24 at 02:30 +0600, Zahid Parvez wrote: Sir I have successfully installed GRASS GIS software in my PC from the link http://grass.osgeo.org/grass63/binary/mswindows/;. I installed in c:\ GRASS folder. I have installed Spearfish and northDakoda data in GIS DataBase folder. Now I wonder how can I start my learning.Would you please give me advice on a way to start learning the soft systematically and effectively. My heartiest gratitude for your kind help. Sincerely Yours Md. Zahid Parvez M.S.C student Bangladesh Engineering University(B.U.E.T) Dhaka,Bangladesh ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Alexandre Swarowsky Soils and Biogeochemistry Graduate Group University of California at Davis One Shields Avenue Davis CA 95618 Office: (530)752-4131 cell: (530)574-3028 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
