Re: [GRASS-user] problem with export of raster data
Markus Neteler wrote: On Mon, Feb 23, 2009 at 12:15 PM, FAROUX STEPHANIE wrote: Hello I try to export a raster integer map whose values range from - to 5880712. How can i specify that i want integer 4 bytes and not integer 2 bytes (it makes integer 2 bytes)?? If you export with r.out.gdal you can choose among type File type options: Byte,Int16,UInt16,Int32,UInt32,Float32,Float64,CInt16, CInt32,CFloat32,CFloat64 This is the range which GRASS support for export to GDAL supported formats (of course it depends if the format is compatible with the selected type, see GDAL manual pages for details). Markus Yes i saw it. However i wonder what is the difference between Uint32, Int32, CInt32? I suppose: unsigned integer 32 bits for the first, but the others? Then, i want binary files, what should i choose among the proposed formats? I tried with no format and with GTiff format. For example when i do: "r.out.gdal input=world_fa2 format=GTiff2 type=Int32 output=world_fa_gdal" or "r.out.gdal input=world_fa2 format=GTiff2 type=UInt32 output=world_fa_gdal" or "r.out.gdal input=world_fa2 format=GTiff2 type=CInt32 output=world_fa_gdal" it doesn't work and i get: *** buffer overflow detected ***: g.parser terminated === Backtrace: = /lib64/libc.so.6(__fortify_fail+0x37)[0x2b42e8de0157] /lib64/libc.so.6[0x2b42e8dde7e0] /lib64/libc.so.6[0x2b42e8b9] /lib64/libc.so.6(_IO_default_xsputn+0x8e)[0x2b42e8d65b5e] /lib64/libc.so.6(_IO_vfprintf+0x1633)[0x2b42e8d3b9b3] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x2b42e8ddde5d] /lib64/libc.so.6(__sprintf_chk+0x80)[0x2b42e8a0] g.parser(main+0x2b9)[0x4012b9] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b42e8d16074] g.parser[0x400ea9] === Memory map: 0040-00402000 r-xp 08:01 199895 /usr/lib64/grass62/bin/g.parser 00602000-00603000 rw-p 2000 08:01 199895 /usr/lib64/grass62/bin/g.parser 00603000-00624000 rw-p 00603000 00:00 0 [heap] 2b42e81bc000-2b42e81d6000 r-xp 08:01 65538 /lib64/ld-2.7.so 2b42e81d6000-2b42e81d8000 rw-p 2b42e81d6000 00:00 0 2b42e83d5000-2b42e83d6000 r--p 00019000 08:01 65538 /lib64/ld-2.7.so 2b42e83d6000-2b42e83d7000 rw-p 0001a000 08:01 65538 /lib64/ld-2.7.so 2b42e83d7000-2b42e8427000 r-xp 08:01 222338 /usr/lib64/grass62/lib/libgrass_gis.6.2.3.so 2b42e8427000-2b42e8626000 ---p 0005 08:01 222338 /usr/lib64/grass62/lib/libgrass_gis.6.2.3.so 2b42e8626000-2b42e8629000 rw-p 0004f000 08:01 222338 /usr/lib64/grass62/lib/libgrass_gis.6.2.3.so 2b42e8629000-2b42e8641000 rw-p 2b42e8629000 00:00 0 2b42e8641000-2b42e8648000 r-xp 08:01 222312 /usr/lib64/grass62/lib/libgrass_datetime.6.2.3.so 2b42e8648000-2b42e8848000 ---p 7000 08:01 222312 /usr/lib64/grass62/lib/libgrass_datetime.6.2.3.so 2b42e8848000-2b42e8849000 rw-p 7000 08:01 222312 /usr/lib64/grass62/lib/libgrass_datetime.6.2.3.so 2b42e8862000-2b42e8876000 r-xp 08:01 65654 /lib64/libz.so.1.2.3 2b42e8876000-2b42e8a75000 ---p 00014000 08:01 65654 /lib64/libz.so.1.2.3 2b42e8a75000-2b42e8a76000 rw-p 00013000 08:01 65654 /lib64/libz.so.1.2.3 2b42e8a76000-2b42e8a77000 rw-p 2b42e8a76000 00:00 0 2b42e8a77000-2b42e8af6000 r-xp 08:01 65553 /lib64/libm-2.7.so 2b42e8af6000-2b42e8cf6000 ---p 0007f000 08:01 65553 /lib64/libm-2.7.so 2b42e8cf6000-2b42e8cf7000 r--p 0007f000 08:01 65553 /lib64/libm-2.7.so 2b42e8cf7000-2b42e8cf8000 rw-p 0008 08:01 65553 /lib64/libm-2.7.so 2b42e8cf8000-2b42e8e43000 r-xp 08:01 65545 /lib64/libc-2.7.so 2b42e8e43000-2b42e9042000 ---p 0014b000 08:01 65545 /lib64/libc-2.7.so 2b42e9042000-2b42e9046000 r--p 0014a000 08:01 65545 /lib64/libc-2.7.so 2b42e9046000-2b42e9047000 rw-p 0014e000 08:01 65545 /lib64/libc-2.7.so 2b42e9047000-2b42e904e000 rw-p 2b42e9047000 00:00 0 2b42e904e000-2b42e908d000 r--p 08:01 565776 /usr/share/locale/UTF-8/LC_CTYPE 2b42e908d000-2b42e9094000 r--s 08:01 500251 /usr/lib64/gconv/gconv-modules.cache 2b42e9094000-2b42e9095000 r--p 08:01 565931 /usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES 2b42e9095000-2b42e90f5000 r--p 08:01 222408 /usr/lib64/grass62/locale/fr/LC_MESSAGES/grassmods.mo 2b42e90f5000-2b42e90f6000 r-xp 08:01 500166 /usr/lib64/gconv/ISO8859-1.so 2b42e90f6000-2b42e92f6000 ---p 1000 08:01 500166 /usr/li
Re: [GRASS-user] problem with export of raster data
FAROUX STEPHANIE wrote: Markus Neteler wrote: On Mon, Feb 23, 2009 at 12:15 PM, FAROUX STEPHANIE wrote: Hello I try to export a raster integer map whose values range from - to 5880712. How can i specify that i want integer 4 bytes and not integer 2 bytes (it makes integer 2 bytes)?? If you export with r.out.gdal you can choose among type File type options: Byte,Int16,UInt16,Int32,UInt32,Float32,Float64,CInt16, CInt32,CFloat32,CFloat64 This is the range which GRASS support for export to GDAL supported formats (of course it depends if the format is compatible with the selected type, see GDAL manual pages for details). Markus Yes i saw it. However i wonder what is the difference between Uint32, Int32, CInt32? I suppose: unsigned integer 32 bits for the first, but the others? Then, i want binary files, what should i choose among the proposed formats? I tried with no format and with GTiff format. For example when i do: "r.out.gdal input=world_fa2 format=GTiff2 type=Int32 output=world_fa_gdal" or "r.out.gdal input=world_fa2 format=GTiff2 type=UInt32 output=world_fa_gdal" or "r.out.gdal input=world_fa2 format=GTiff2 type=CInt32 output=world_fa_gdal" I think it must be GTiff and not GTiff2. The command would be r.out.gdal input=world_fa2 format=GTiff type=Int32 output=world_fa_gdal.tif BTW, no format defaults to GTiff format in r.out.gdal. UInt32 is unsigned integer 32 bit, yes. Int32 is signed integer 32 bit, CInt32 is complex signed integer 32 bit (not supported by grass). With world_fa2 (range is - to 5880712, yes?), Int32 seems the right choice. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem with export of raster data
On Tue, Feb 24, 2009 at 10:14 AM, Markus Metz wrote: > FAROUX STEPHANIE wrote: > UInt32 is unsigned integer 32 bit, yes. Int32 is signed integer 32 bit, > CInt32 is complex signed integer 32 bit (not supported by grass). With > world_fa2 (range is - to 5880712, yes?), Int32 seems the right choice. See also the "Ranges of GDAL data types" table in: http://grass.osgeo.org/gdp/html_grass64/r.out.gdal.html Just wanted to suggest to add it but it's already there :) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] convert r.report output to spreadsheet format
Hi, Looking for tips in "transforming" r.report output into a "spreadsheet" like format. -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] convert r.report output to spreadsheet format
Maning,
Depends on what you are doing with r.report, but you can often use r.stats
instead, to output a csv file (look at docs for r.stats if you want percent
or cell counts, my example assumes area counts).
r.stats -an fs="," input=raster1,raster2
If you need to do a unit conversion ie m^2 to acres, use awk:
r.stats -an input=raster1,raster2 | awk -F, '{acres=$3*0.00024710538; print
$1" "$2" "acres}' > output.txt
Jonah Duckles
Senior Analyst
Lanworth
On Tue, Feb 24, 2009 at 5:37 AM, maning sambale
wrote:
> Hi,
>
> Looking for tips in "transforming" r.report output into a
> "spreadsheet" like format.
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.com/
> --
> ___
> 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] convert r.report output to spreadsheet format
maning sambale ha scritto:
Hi,
Looking for tips in "transforming" r.report output into a
"spreadsheet" like format.
Hi,
I use awk (change NF and the other fields $*):
r.report -n map=gri_1000_in,dem2_idw_100_slope_rec units=h,p,c | awk
'BEGIN {FS="|";OFS="|"} !/---/ && NF==7 {intest=$2} NF==8 {sub(/[
.]*$/,"",$4); print intest, $4, $6}' > report_slope.txt
This from a non awk expert!
cheers,
giovanni
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] mapset cell size grouping
Greetings. Is it logical to use mapsets for different raster modeling cell sizes? I end up doing a lot of data runs with the hydrology tools on a DEM in GRASS, and rather than changing the region cell size each time (from something like 50 foot cells vs. 25 foot cells) within the mapset, I found that using a mapset with the different cell sizes is working very well so far. Putting all the output data (from something like r.watershed) with different cell resolutions in the same mapset, gets to be quite a lot of data to manage when looking to compare output results. Is there a pitfall to this approach of using mapsets with different cell sizes, or is there another recommendation to working with different cell size rasters on the same project? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mapset cell size grouping
M S: > Is it logical to use mapsets for different raster modeling cell sizes? I had the same problem: I needed to switch frequently between 250 and 500m (MODIS products). I tried the mutltiple-mapsets approach and found it not bad. Nonetheless, I had _not_ too many images to process (and mainly working with the 500m pics) and therefore I decided to stick with one mapset. I think that your approach makes sense and don't see important drawbacks. Kind regards, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mapset cell size grouping
> Is it logical to use mapsets for different raster modeling > cell sizes? sure, use whatever works. you can use g.mapset (no "s") to change mapsets on the fly, but it might help to change the path (PS1= enviro var) to include the mapset name instead of the location name in the prompt. that's set in etc/init.sh at startup, so maybe need to edit $GISBASE/etc/prompt.sh to have that change automatically when g.mapset changes? e.g. after each g.mapset change: eval `g.gisenv` export PS1='GRASS ($MAPSET):\W > ' all-in-one: g.mapset user1 && eval `g.gisenv` && export PS1='GRASS ($MAPSET):\W > ' probably add the shell history recommendations from g.mapset to that, and perhaps source it in a little ". source.sh" command. (you can make an alias to avoid the ". file.sh" each time) sumthin' like that... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem using i.cluster on GRASS GIS 6.4.0RC3
sindile.bidla wrote:
> I get the following error when using i.cluster: ERROR:
> Unable to create report file <(null)>
>
> This is how I wrote the commands
> i.group group=lsat1 subgroup=lsat1
> in=L71171078_07820001007_B10,L71171078_07820001007_B20,L71171078_07820001007_B30,L71171078_07820001007_B40,L71171078_07820001007_B50,L72171078_07820001007_B70
> i.cluster group=lsat1 subgroup=lsat1 sig=sig.cluster
> classes=15 sep=1.5
>
> Windows XP - GRASS GIS 6.4.0RC3
>
> I have seen the following tickets
> http://trac.osgeo.org/grass/ticket/174 and
> http://trac.osgeo.org/grass/ticket/70 which seem to suggest
> that the
> problem has been solved / there is a work around.
nope, not fixed yet.
i.cluster/main.c has:
if ((reportfile = parm.report_file->answer) == NULL)
report = fopen("/dev/null", "w");
there is no /dev/null on Windows, so it fails to open the file.
work-around: specify reportfile=something.txt
others that need fixing:
raster/r.out.mpeg/main.c
raster/r.topmodel/misc.c
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] convert r.report output to spreadsheet format
Thanks!
An example of the r.report output:
|-|
| Category Information | | cell| % |
| #|description | hectares|count| cover|
|-|
| 1|Siquijor |31,313| 385511| 0.05|
| |--|--|-|--|
| |112|Broadleaf - open canopy. . . . . . . . . .| 8265| 101755| 26.39|
| |140|Mangrove . . . . . . . . . . . . . . . . .| 173| 2125| 0.55|
| |210|Agriculture-annual . . . . . . . . . . . .| 7370|90737| 23.54|
| |310|Scrub. . . . . . . . . . . . . . . . . . .| 1063|13081| 3.39|
| |320|Grassland. . . . . . . . . . . . . . . . .| 7185|88460| 22.95|
| |400|Built-up . . . . . . . . . . . . . . . . .| 103| 1270| 0.33|
| |510|Inland water . . . . . . . . . . . . . . .|44| 539| 0.14|
| | *|no data. . . . . . . . . . . . . . . . . .| 7111|87544| 22.71|
I want converted to:
Province,land_cover_code,description,hectares,cell_count,percent_cover
I will try the cryptic awk lines.
On Wed, Feb 25, 2009 at 12:12 AM, Giovanni Pasini wrote:
> maning sambale ha scritto:
>>
>> Hi,
>>
>> Looking for tips in "transforming" r.report output into a
>> "spreadsheet" like format.
>>
>
> Hi,
> I use awk (change NF and the other fields $*):
>
> r.report -n map=gri_1000_in,dem2_idw_100_slope_rec units=h,p,c | awk 'BEGIN
> {FS="|";OFS="|"} !/---/ && NF==7 {intest=$2} NF==8 {sub(/[ .]*$/,"",$4);
> print intest, $4, $6}' > report_slope.txt
>
> This from a non awk expert!
>
> cheers,
> giovanni
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
--
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] convert r.report output to spreadsheet format
If I understood you correctly you want to convert the below text formatted
table in a spreadsheet like format. If this is the case why do not you try the
OpenOffice.org calc possibility of fixed delimitation. Save the output of
r.report in a file with a .csv suffix. Then open it in ooo calc and set for
your delimitation fixed width. Then determine manually the coulumn limits. and
with a bit of editing you are done.
Hope it helps
Miha
--- On Wed, 25/2/09, maning sambale wrote:
> From: maning sambale
> Subject: Re: [GRASS-user] convert r.report output to spreadsheet format
> To: "grass mailing list"
> Date: Wednesday, 25 February, 2009, 7:51 AM
> Thanks!
> An example of the r.report output:
> |-|
> | Category Information |
> | cell| % |
> | #|description |
> hectares|count| cover|
> |-|
> | 1|Siquijor |
> 31,313| 385511| 0.05|
> |
> |--|--|-|--|
> | |112|Broadleaf - open canopy. . . . . . . . . .|
> 8265| 101755| 26.39|
> | |140|Mangrove . . . . . . . . . . . . . . . . .|
> 173| 2125| 0.55|
> | |210|Agriculture-annual . . . . . . . . . . . .|
> 7370|90737| 23.54|
> | |310|Scrub. . . . . . . . . . . . . . . . . . .|
> 1063|13081| 3.39|
> | |320|Grassland. . . . . . . . . . . . . . . . .|
> 7185|88460| 22.95|
> | |400|Built-up . . . . . . . . . . . . . . . . .|
> 103| 1270| 0.33|
> | |510|Inland water . . . . . . . . . . . . . . .|
> 44| 539| 0.14|
> | | *|no data. . . . . . . . . . . . . . . . . .|
> 7111|87544| 22.71|
>
> I want converted to:
> Province,land_cover_code,description,hectares,cell_count,percent_cover
>
> I will try the cryptic awk lines.
>
>
> On Wed, Feb 25, 2009 at 12:12 AM, Giovanni Pasini
> wrote:
> > maning sambale ha scritto:
> >>
> >> Hi,
> >>
> >> Looking for tips in "transforming"
> r.report output into a
> >> "spreadsheet" like format.
> >>
> >
> > Hi,
> > I use awk (change NF and the other fields $*):
> >
> > r.report -n map=gri_1000_in,dem2_idw_100_slope_rec
> units=h,p,c | awk 'BEGIN
> > {FS="|";OFS="|"} !/---/ &&
> NF==7 {intest=$2} NF==8 {sub(/[ .]*$/,"",$4);
> > print intest, $4, $6}' > report_slope.txt
> >
> > This from a non awk expert!
> >
> > cheers,
> > giovanni
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all"
> -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.com/
> --
> ___
> 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
