Re: [GRASS-user] Best format for exporting raster data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/08/10 16:56, Sylvain Maillard wrote: Perhaps can you add an extra loop in your scripts for processing your data: 1 - extract the tarball 2 - import the raster in R 3 - and then delete the temporary uncompressed mapset. Yes - that would be the crude force approach. In my case, it would very likely take more time, as there are MANY more layers in the .tar.gz then I use. I am now thinking about extracting all files with fire in them and to use this subset as a mapset - I will see if it works. It would be nice, if grass would be able to deal with on-the-fly decompression - not from a .tar.gz file, but from gz compressed files. Cheers, Rainer it will take a little bit more space but just for one mapset at a time, and I don't thing the process will be much slower than to access the files directly into the compressed tarball ... you can also buy more hard drive :D if you make some benchmark test between different solution I will be interreted in the results, I'm also working on a huge amound of raster data within GRASS and R ... I'll do - although I don't think I will do benchmarks at that time. Cheers, Rainer regards, Sylvain Maillard Doctorant en Sciences de l'Environnement Laboratoire Chimie Provence - UMR 6264 / Université de Provence la Tour du Valat - Centre de recherche pour la conservation des zones humides méditerranéennes Le Sambuc 13200 Arles France tél:04.90.97.29.79 fax:04.90.97.20.19 www.tourduvalat.org http://www.tourduvalat.org 2010/8/31 Rainer M Krug r.m.k...@gmail.com mailto:r.m.k...@gmail.com On 31/08/10 16:38, Markus Neteler wrote: On Tue, Aug 31, 2010 at 4:13 PM, Rainer M Krug r.m.k...@gmail.com mailto:r.m.k...@gmail.com wrote: ... I would leave it in GRASS and use the R-GRASS interface and/or the GDAL-GRASS plugin. See the Wiki for details. I am doing that already - but I don't think that works when I have the grass mapset compressed as a .tar.gz? I found archivemount which apparently lets you mount a possibly compressed tarball as a filesystem: http://en.wikipedia.org/wiki/Archivemount http://www.linux.com/archive/feature/132196 Sounds interesting - I'll look into that. Thanks, Rainer Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org mailto: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 Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Tel:+33 - (0)9 53 10 27 44 Cell: +27 - (0)8 39 47 90 42 Fax (SA): +27 - (0)8 65 16 27 82 Fax (D) : +49 - (0)3 21 21 25 22 44 Fax (FR): +33 - (0)9 58 10 27 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx+C5QACgkQoYgNqgF2egoSOwCeLJPZ4WGaem4o8k+lvDpT5QiG l4gAnRe9trZfFaD+STl7yByUXA3IYiXS =+YiD -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Best format for exporting raster data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/10 10:15, Rainer M Krug wrote: On 31/08/10 16:56, Sylvain Maillard wrote: Perhaps can you add an extra loop in your scripts for processing your data: 1 - extract the tarball 2 - import the raster in R 3 - and then delete the temporary uncompressed mapset. Yes - that would be the crude force approach. In my case, it would very likely take more time, as there are MANY more layers in the .tar.gz then I use. I am now thinking about extracting all files with fire in them and to use this subset as a mapset - I will see if it works. It would be nice, if grass would be able to deal with on-the-fly decompression - not from a .tar.gz file, but from gz compressed files. Cheers, Rainer it will take a little bit more space but just for one mapset at a time, and I don't thing the process will be much slower than to access the files directly into the compressed tarball ... you can also buy more hard drive :D if you make some benchmark test between different solution I will be interreted in the results, I'm also working on a huge amound of raster data within GRASS and R ... I'll do - although I don't think I will do benchmarks at that time. I am trying archivemounter and it has some interesting benchmarks on the website http://www.linux.com/archive/feature/132196 Cheers, Rainer Cheers, Rainer regards, Sylvain Maillard Doctorant en Sciences de l'Environnement Laboratoire Chimie Provence - UMR 6264 / Université de Provence la Tour du Valat - Centre de recherche pour la conservation des zones humides méditerranéennes Le Sambuc 13200 Arles France tél:04.90.97.29.79 fax:04.90.97.20.19 www.tourduvalat.org http://www.tourduvalat.org 2010/8/31 Rainer M Krug r.m.k...@gmail.com mailto:r.m.k...@gmail.com On 31/08/10 16:38, Markus Neteler wrote: On Tue, Aug 31, 2010 at 4:13 PM, Rainer M Krug r.m.k...@gmail.com mailto:r.m.k...@gmail.com wrote: ... I would leave it in GRASS and use the R-GRASS interface and/or the GDAL-GRASS plugin. See the Wiki for details. I am doing that already - but I don't think that works when I have the grass mapset compressed as a .tar.gz? I found archivemount which apparently lets you mount a possibly compressed tarball as a filesystem: http://en.wikipedia.org/wiki/Archivemount http://www.linux.com/archive/feature/132196 Sounds interesting - I'll look into that. Thanks, Rainer Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org mailto: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 Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Tel:+33 - (0)9 53 10 27 44 Cell: +27 - (0)8 39 47 90 42 Fax (SA): +27 - (0)8 65 16 27 82 Fax (D) : +49 - (0)3 21 21 25 22 44 Fax (FR): +33 - (0)9 58 10 27 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx+D7kACgkQoYgNqgF2egrYKwCfSRRC23jZdwv8S30jrtFFp2hu 0X4AoIIbHJ/ZccwilSmaTcM7YJCa6tDZ =P1+t -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Best format for exporting raster data
Rainer M Krug wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am creating a huge amount of raster layers during my simulations, and I would like to archive then to enable further analysis. At the moment I am leaving them in the grass database and compress the whole mapset into a tar.gz file. But this is rather cumbersome, if I want to extract some selected layers and analyse them further (my analysis is done in R). Therefore I would like to export the created layers while the simulation is running and to delete them from the grass database. My question: what is the best format for this? It should : - - contain all the information contained in the raster layer in the grass mapset - - be readable by at least gdal - - be preferably compressed (but I can compress them after export) At the moment I am using for a similar purpose the esri asc grid, but I am somehow critical about the fact that it uses a text representation of my data with limited decimals, therefore probably loosing information compared with the grass file. Are Binary fiels a better option (in the manual it states Exports, not converts as in the esri ascii grid) and can I read them from R or gdal? Raster data (the actual data grids) are already compressed in GRASS, nothing much to gain there to compress already compressed data. You can try to set GRASS_INT_ZLIB [1] and check if this gives better compression than the default RLE for CELL maps. Generally, the recommended export format is GeoTIFF which supports various internal compression methods. A high compression ratio is achieved with LZW and DEFLATE. Not all packages using gdal support all gdal features, DEFLATE in particular is often not supported by packages using their own modified gdal version (does not apply to packages using an external gdal library, e.g. GRASS, R, QGIS). Markus M [1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] syntax for setting GRASS_PNGFILE from Python script
Hi,
2010/8/31 Damian M maddal...@nc.rr.com:
GRASS_PNGFILE=mywaycoolmap.png
export GRASS_PNGFILE
What is the proper syntax for setting this in Python?
I have tried something like:
def jpgMap():
#SET PNG OUTPUT FILE NAME
grass.run_command(g.gisenv, set=GRASS_PNGFILE=testName.png)
GRASS_PNGFILE is a shell environment variable, not a GRASS gisenv
variable [1]. To set environment variable use e.g. os.putenv()
os.putenv('GRASS_PNGFILE', 'test.png')
Martin
[1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.extension not working
I just issued make install and installed grass65 at /usr/local/grass-6.5.svn. Now, g.extension tries to install r.stream.order but complains about permissions. Taking ownership of the install dir fixes the problem. So, what would be the correct way to use g.extension, run grass as root or take ownership of the install dir? Cheers Daniel On Wed, Sep 1, 2010 at 2:39 AM, Markus Neteler nete...@osgeo.org wrote: Yes, that's the reason then (same here). We need to add a condition to skip the install ste in this case. Markus On 9/1/10, Daniel Victoria daniel.victo...@gmail.com wrote: I do have /usr/bin/install installed. I run Ubuntu and coreutils is the latest version. One small quirk though. I compiled Grass 6.5svn running make but I did not install it (make install). I'm running it straigh from the build directory (start script at ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu). Could that be related? Thanks Daniel On Tue, Aug 31, 2010 at 10:01 PM, Hamish hamis...@yahoo.com wrote: Daniel wrote: Ok, g.extension works and downloads svn addons great! thanks for the confirmation. but r.stream.extract compilation fails. ... Bellow is the r.stream.order compilation log error. ... make[1]: Leaving directory ok, so actually it built ok, but fails during installation: Installing r.stream.order... ... /usr/bin/install: cannot stat aka the install program is not installed. No idea what provides that on your linux distro, on Debian and Ubuntu it comes in the coreutils package. Hamish ___ 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] Raster resolution problems
Hi, I'm using GRASS6.4SVN on Windows XP. I want to import TRMM precipitation data into a GRASS projected (Transverse Mercator) location. I have previously successfully import this data to a GCS (WGS84) location using the procedure at http://grass.osgeo.org/wiki/Import_XYZ. My problem is the grid resolution. The TRMM grid consists of 0.25° squares, but projected they have different sizes. Here is the output from v.report (area in km2) for a vector layer with the TRMM grid squares, projected into the Transverse Mercator location: - cat|LabelX|LabelY|LblOffsetX|LblOffsetY|Label|gRow|gColumn|RowCol|area 5|28.25|-28.75|-20|-20|28.25677.428350142518 11|28.5|-28.5|-20|-20|28.5678.961903132767 6|28.25|-28.5|-20|-20|28.25679.002141385312 1|28|-28.5|-20|-20|28679.062503849138 12|28.5|-28.25|-20|-20|28.5680.522519692921 7|28.25|-28.25|-20|-20|28.25680.563040996854 2|28|-28.25|-20|-20|28680.623828116383 13|28.5|-28|-20|-20|28.5682.070220966439 8|28.25|-28|-20|-20|28.25682.111024322052 3|28|-28|-20|-20|28682.172234597964 14|28.5|-27.75|-20|-20|28.5683.604982570918 9|28.25|-27.75|-20|-20|28.25683.646066944101 4|28|-27.75|-20|-20|28683.70769882544 15|28.5|-27.5|-20|-20|28.5685.126780361735 10|28.25|-27.5|-20|-20|28.25685.168144684034 - The projected grid 'squares' vary in size from 677km2 to 685km2. So how am I supposed to set the resolution of the region when I do the import? (I previously tried to reproject the TRMM data from the GCS location to the Transverse Mercator location, but then I ran into the same problem - resolution. Any ideas? Thanks Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Best format for exporting raster data
Rainer M Krug wrote: It would be nice, if grass would be able to deal with on-the-fly decompression - not from a .tar.gz file, but from gz compressed files. GRASS rasters are already compressed by default, either using RLE or zlib compression (OTOH, the null bitmap isn't compressed; that will cease to be an issue if we embed nulls into the raster data). But GRASS doesn't generally read data from files per se, but from either the GRASS database or from GDAL (and the former might eventually go away if we can get native GRASS support into GDAL). The main issue with on-the-fly decompression using general-purpose formats is that rasters aren't guaranteed to be read sequentially, while compression algorithms require sequential access. Similarly, while there exist filesystems which can mount archives, tar files (and especially compressed tar files) are a poor choice, as they are designed for sequential access. ZIP/RAR are more suited to such tasks. Ultimately, I don't think that this situation is common enough to be worth doing anything about. If you want to access archived data, you just unpack the archives first (or use an archive format which can be mounted). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] syntax for setting GRASS_PNGFILE from Python script
Martin Landa wrote:
GRASS_PNGFILE=mywaycoolmap.png
export GRASS_PNGFILE
What is the proper syntax for setting this in Python?
I have tried something like:
def jpgMap():
#SET PNG OUTPUT FILE NAME
grass.run_command(g.gisenv, set=GRASS_PNGFILE=testName.png)
GRASS_PNGFILE is a shell environment variable, not a GRASS gisenv
variable [1]. To set environment variable use e.g. os.putenv()
os.putenv('GRASS_PNGFILE', 'test.png')
If you want to set an environment variable for the duration of a
script, the preferred mechanism is to modify the os.environ array,
i.e.:
os.environ['GRASS_PNGFILE'] = 'test.png'
Modifying os.environ will call os.putenv() if it is available (it
doesn't exist on all platforms supported by Python), but calling
os.putenv() doesn't modify os.environ, so calling os.putenv() will
result in os.environ and the actual environment used by subprocesses
getting out of sync.
If you want to set an environment variable for specific commands, use
the env parameter to run_command() etc to pass an updated
environment, e.g.:
environ = os.environ.copy()
environ['GRASS_PNGFILE'] = 'test.png'
grass.run_command(..., env = environ)
This approach should be used if you will be running different commands
with different environment settings. Changing os.environ then
reverting it after the command completes is error-prone and should not
be used. Only modify os.environ if the changes will be permanent
(i.e. for the duration of the script).
--
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.extension not working
Daniel Victoria wrote: I just issued make install and installed grass65 at /usr/local/grass-6.5.svn. Now, g.extension tries to install r.stream.order but complains about permissions. Taking ownership of the install dir fixes the problem. So, what would be the correct way to use g.extension, run grass as root or take ownership of the install dir? Maybe you could just ignore the install-related error messages and check if r.stream.order is available when you are running grass straight from the build directory (start script at ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu) In this case, i.e. running grass from the build directory, you could download any addon to the appropriate directory, run make and it should be available (not sure about manuals though, which are important...) when running grass from the build directory. Otherwise, if you installed grass as root (make install as root), you most probably also have to install addons as root. HTH, Markus M Cheers Daniel Markus Neteler wrote: Yes, that's the reason then (same here). We need to add a condition to skip the install ste in this case. Markus Daniel Victoria wrote: I do have /usr/bin/install installed. I run Ubuntu and coreutils is the latest version. One small quirk though. I compiled Grass 6.5svn running make but I did not install it (make install). I'm running it straigh from the build directory (start script at ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu). Could that be related? Thanks Daniel Hamish wrote: Daniel wrote: Ok, g.extension works and downloads svn addons great! thanks for the confirmation. but r.stream.extract compilation fails. ... Bellow is the r.stream.order compilation log error. ... make[1]: Leaving directory ok, so actually it built ok, but fails during installation: Installing r.stream.order... ... /usr/bin/install: cannot stat aka the install program is not installed. No idea what provides that on your linux distro, on Debian and Ubuntu it comes in the coreutils package. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.extension not working
On Wed, Sep 1, 2010 at 8:52 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Daniel Victoria wrote: I just issued make install and installed grass65 at /usr/local/grass-6.5.svn. Now, g.extension tries to install r.stream.order but complains about permissions. Taking ownership of the install dir fixes the problem. So, what would be the correct way to use g.extension, run grass as root or take ownership of the install dir? Maybe you could just ignore the install-related error messages and check if r.stream.order is available when you are running grass straight from the build directory (start script at ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu) In this case, i.e. running grass from the build directory, you could download any addon to the appropriate directory, run make and it should be available (not sure about manuals though, which are important...) when running grass from the build directory. Otherwise, if you installed grass as root (make install as root), you most probably also have to install addons as root. Perhaps we need to add some sudo magic...? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.extension not working
Markus Neteler: Markus Metz: Daniel Victoria wrote: I just issued make install and installed grass65 at /usr/local/grass-6.5.svn. Now, g.extension tries to install r.stream.order but complains about permissions. Taking ownership of the install dir fixes the problem. So, what would be the correct way to use g.extension, run grass as root or take ownership of the install dir? Maybe you could just ignore the install-related error messages and check if r.stream.order is available when you are running grass straight from the build directory (start script at ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu) In this case, i.e. running grass from the build directory, you could download any addon to the appropriate directory, run make and it should be available (not sure about manuals though, which are important...) when running grass from the build directory. Otherwise, if you installed grass as root (make install as root), you most probably also have to install addons as root. Perhaps we need to add some sudo magic...? Probably yes. The standard situation might be that a user installs from a repository grass and grass-devel (or simliar) which usually requires root privileges. In turm g.extension will require root priviliges. Right? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Finding the value of a point in a raster map
Hi, I am writing a r.mapcalc instruction, and I would like to find the value of a point in the map (other than the point that the window is currently at). More precisely, in a raster dem I would like to calculate the difference between the height of one point and the rest of the map. I appreciate if any one can help. Thanks, Ahmad ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
