[GRASS-user] Geotiff files
Pawan Joshi
josh_0882 at yahoo.com
Tue May 1 01:20:18 EDT 2007
I have some tif files, i want to extract the spatical data from then what should i do. I am now using GRASS 6.2 and i have done the following
r.in.gdal input=xxx.tif output=yy
AN error message
then i use
r.in.gdal -o input=xxx.tif output=yy
it creats three files in my mapset by the name of yy.red,yy.blue,yy.green, what about spatical data.
Thanks,
Pawan
grassuser-request at grass.itc.it wrote: Send grassuser mailing list submissions to
grassuser at grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit
http://grass.itc.it/mailman/listinfo/grassuser
or, via email, send a message with subject or body 'help' to
grassuser-request at grass.itc.it
You can reach the person managing the list at
grassuser-owner at grass.itc.it
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grassuser digest..."
Today's Topics:
1. linear referencing system - has anyone used it? (Lindsay Mico)
2. Re: gis.m fails in latest cvs and black images from nivz
(Maciej Sieczka)
3. Re: gis.m fails in latest cvs and black images from nivz
( Carlos "Gu?no" Grohmann )
4. New Mac OS X application build option (William Kyngesburye)
5. Re: linear referencing system - has anyone used it? (Trevor Wiens)
6. Re: [GRASS-dev] New Mac OS X application build option
(Michael Barton)
7. Re: r.in.srtm help, again (Hamish)
8. Re: ascii to dem (Hamish)
9. Datum transformations (Jose Gomez-Dans)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Mar 2007 12:37:28 -0800
From: "Lindsay Mico"
Subject: [GRASS-user] linear referencing system - has anyone used it?
To: grassuser at grass.itc.it
Message-ID:
Content-Type: text/plain; format=flowed
I posted a question a few weeks ago about the linear referencing system.
Has anyone actually used it to make new maps from field data? Unfortunately
the developer of this function (Radim Blazek) no longer works on Grass.
Below is a copy of my original question.
Thanks and cheers.
Fellow GRASS users,
I would like to build a new point data layer from a large database of stream
surveys which have 2 pieces of spatial info:
1) an LLID number for that stream
2) distance from the start of that stream
Based on what I have seen, I would use the linear referencing system
modules. I am not sure if I need to build a new reference layer as I have a
stream layer with the LLID info already in it. Additionally, I could not
find an example of how v.lrs.segment works in practice. I have attempted to
summarize things as I understand it to help make it easier to answer my
questions. As I understand it the input parameters for v.lrs.segment would
be as follows:
1) input= the stream layer with the associated LLID info
2) output = the name of the output layer
3) llayer = whether it is a point or line (is it 1 for line and 0 for
point?)
4) rsdriver = I don't know what this means
5) rsdatabase = the location of the file with the LLID # and distance
6) rstable = the name of the file which has the LLID number and distance?
will it automatically add in the other data in the database? Or do I do
that later using a spreadsheet program on the .dbf
As I am still learning how to do this, I expect I will have more questions
in the future. Hopefully this will be of use to others as well. Many
thanks in advance. Cheers.
Lindsay Mico
Environmental Consultant
Demeter Design LLC
(503) 368-7195
http://demeterdesign.net
"Thoughtful Planning is the Surest Investment"
------------------------------
Message: 2
Date: Wed, 14 Mar 2007 22:46:19 +0100
From: Maciej Sieczka
Subject: Re: [GRASS-user] gis.m fails in latest cvs and black images
from nivz
To: "Carlos \"Gu?no\" Grohmann"
Cc: grass user
Message-ID: <45F86D2B.1000502 at o2.pl>
Content-Type: text/plain; charset=ISO-8859-2
Carlos "Guâno" Grohmann wrote:
> Hello all.
>
> I just compiled the latest cvs (Ubuntu 6.10), and gis.m fails with
> "child proccess exited abnormally"... just after I select the
> Location/Mapaset for the session.
I don't confirm, using fresh 6.3 CVS on Ubuntu 6.06.1 Dapper
> Also, when in nviz (both with 6.2.1 and with 6.3cvs), when I try to
> save the view as an image (ppm, tiff, or max.res. ppm), all I get is a
> black image.
For me saving to ppm and tiff work OK. Saving to max res ppm however
results in over 40 black or corrupted ppms, some of them ahving the
'tmp' in their name, like if they were some remainments of temporary files.
Anyway, I cannot confirm other of your problems.
For a wild guess, I tried changing my shell from bash to dash, wchich
Ubuntu 6.10 uses by default. This doesn't brake anything either. Both
bash and dash let the startup gui, gis.m and nviz run fine.
Maciek
------------------------------
Message: 3
Date: Wed, 14 Mar 2007 19:06:14 -0300
From: " Carlos \"Gu?no\" Grohmann "
Subject: Re: [GRASS-user] gis.m fails in latest cvs and black images
from nivz
Cc: "grass user"
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Well I did a completely fresh install (removed old grass, downloaded
again.. etc) and now its working, except for the ppm/tiff export from
NVIZ. still only black images.
Carlos
On 3/14/07, Maciej Sieczka wrote:
> Carlos "Guâno" Grohmann wrote:
> > Hello all.
> >
> > I just compiled the latest cvs (Ubuntu 6.10), and gis.m fails with
> > "child proccess exited abnormally"... just after I select the
> > Location/Mapaset for the session.
>
> I don't confirm, using fresh 6.3 CVS on Ubuntu 6.06.1 Dapper
>
> > Also, when in nviz (both with 6.2.1 and with 6.3cvs), when I try to
> > save the view as an image (ppm, tiff, or max.res. ppm), all I get is a
> > black image.
>
> For me saving to ppm and tiff work OK. Saving to max res ppm however
> results in over 40 black or corrupted ppms, some of them ahving the
> 'tmp' in their name, like if they were some remainments of temporary files.
>
> Anyway, I cannot confirm other of your problems.
>
> For a wild guess, I tried changing my shell from bash to dash, wchich
> Ubuntu 6.10 uses by default. This doesn't brake anything either. Both
> bash and dash let the startup gui, gis.m and nviz run fine.
>
> Maciek
>
--
+-----------------------------------------------------------+
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
------------------------------
Message: 4
Date: Wed, 14 Mar 2007 17:13:41 -0500
From: William Kyngesburye
Subject: [GRASS-user] New Mac OS X application build option
To: grass-dev at grass.itc.it, grassuser at grass.itc.it
Message-ID:
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Finally got the Mac OS X build option into CVS, with a little
configure/makefile help from Glynn.
To build GRASS as a Mac OS X application (exactly like my binaries,
if anyone has used those), add these options to your configure command:
--prefix=/Applications --enable-macosx-app
Since the default prefix is /usr/local and it's nearly impossible to
have multiple conditional default prefixes in configure, you should
set the prefix as above.
It's tested with OSX 10.4 and the latest Xcode. It should work on
10.3, but it would be good to have verification of this if anyone
cares to try it.
Enjoy!
-----
William Kyngesburye
http://www.kyngchaos.com/
[Trillian] What are you supposed to do WITH a maniacally depressed
robot?
[Marvin] You think you have problems? What are you supposed to do
if you ARE a maniacally depressed robot? No, don't try and answer,
I'm 50,000 times more intelligent than you and even I don't know the
answer...
- HitchHiker's Guide to the Galaxy
------------------------------
Message: 5
Date: Wed, 14 Mar 2007 16:52:29 -0600
From: Trevor Wiens
Subject: Re: [GRASS-user] linear referencing system - has anyone used
it?
To: "Lindsay Mico"
Cc: grassuser at grass.itc.it
Message-ID: <20070314165229.57dd6f77 at localhost.localdomain>
Content-Type: text/plain; charset=US-ASCII
On Wed, 14 Mar 2007 12:37:28 -0800
Lindsay Mico wrote:
> I posted a question a few weeks ago about the linear referencing system.
> Has anyone actually used it to make new maps from field data? Unfortunately
> the developer of this function (Radim Blazek) no longer works on Grass.
> Below is a copy of my original question.
>
> Thanks and cheers.
>
>
> Fellow GRASS users,
>
> I would like to build a new point data layer from a large database of stream
> surveys which have 2 pieces of spatial info:
>
> 1) an LLID number for that stream
> 2) distance from the start of that stream
I've only used v.lrs.segment with single line segments, not networks
of lines. For this I passed this type of information formated as:
P stoptext catnum offset
in a text file and piped it to the command.
>
> Based on what I have seen, I would use the linear referencing system
> modules. I am not sure if I need to build a new reference layer as I have a
> stream layer with the LLID info already in it. Additionally, I could not
> find an example of how v.lrs.segment works in practice. I have attempted to
> summarize things as I understand it to help make it easier to answer my
> questions. As I understand it the input parameters for v.lrs.segment would
> be as follows:
>
> 1) input= the stream layer with the associated LLID info
> 2) output = the name of the output layer
> 3) llayer = whether it is a point or line (is it 1 for line and 0 for
> point?)
Please refer to the GRASS vector intro for details on layers within
vector files. Essentially, unless you are messing with this "feature"
it will always be 1.
> 4) rsdriver = I don't know what this means
dbf, pgsql, sqlite, etc
> 5) rsdatabase = the location of the file with the LLID # and distance
name of database, for example name of sql database.
> 6) rstable = the name of the file which has the LLID number and distance?
table name
> will it automatically add in the other data in the database? Or do I do
> that later using a spreadsheet program on the .dbf
>
> As I am still learning how to do this, I expect I will have more questions
> in the future. Hopefully this will be of use to others as well. Many
> thanks in advance. Cheers.
>
It is useful to read through all the material in the tutorial if you
haven't already done so.
T
--
Trevor Wiens
twiens at interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
------------------------------
Message: 6
Date: Wed, 14 Mar 2007 17:20:04 -0700
From: Michael Barton
Subject: [GRASS-user] Re: [GRASS-dev] New Mac OS X application build
option
To: William Kyngesburye ,
,
Message-ID:
Content-Type: text/plain; charset="US-ASCII"
Cheers to you and Glynn!
Michael
On 3/14/07 3:13 PM, "William Kyngesburye" wrote:
> Finally got the Mac OS X build option into CVS, with a little
> configure/makefile help from Glynn.
>
> To build GRASS as a Mac OS X application (exactly like my binaries,
> if anyone has used those), add these options to your configure command:
>
> --prefix=/Applications --enable-macosx-app
>
> Since the default prefix is /usr/local and it's nearly impossible to
> have multiple conditional default prefixes in configure, you should
> set the prefix as above.
>
> It's tested with OSX 10.4 and the latest Xcode. It should work on
> 10.3, but it would be good to have verification of this if anyone
> cares to try it.
>
> Enjoy!
>
> -----
> William Kyngesburye
> http://www.kyngchaos.com/
>
> [Trillian] What are you supposed to do WITH a maniacally depressed
> robot?
>
> [Marvin] You think you have problems? What are you supposed to do
> if you ARE a maniacally depressed robot? No, don't try and answer,
> I'm 50,000 times more intelligent than you and even I don't know the
> answer...
>
> - HitchHiker's Guide to the Galaxy
>
>
>
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
------------------------------
Message: 7
Date: Thu, 15 Mar 2007 14:09:48 +1300
From: Hamish
Subject: Re: [GRASS-user] r.in.srtm help, again
To: antonio rodriguez
Cc: grassuser at grass.itc.it
Message-ID: <20070315140948.271056b2.hamish_nospam at yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
antonio rodriguez wrote:
> >> I have some bathymetric data from GEBCO which are in .grd format
> >> (GMT) so I've tried:
> >>
> >> r.in.bin -h in=data.grd out=bati
> >>
> >> and I get:
> >>
> >> ERROR: North must be north of south
> >>
> >> The coordinates of the data are 38n/34n 9w/2w
> >>
> >> I've tried too:
> >>
> >> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati
> >
> >> north=38 south=34 east=-2 west=-9
> >>
> >> Using rows=4 cols=11
HB:
> > ^^^^
> >
AR:
> >> ATENCIÓN: Bytes do not match File size
> >> ATENCIÓN: File Size 319216 ... Total Bytes 44
> >> ATENCIÓN: Try bytes=7254 or adjusting input parameters
> >>
> >> So I tried with bytes=7254 (bytes=7255, bytes=7256) but I never get
> >> the right number
> >>
> >> Any idea?
HB:
> > set the correct rows= and cols= options. Right now it is guessing
> > the raster resolution is 1 pixel = 1 degree x 1 degree.
> >
> > note the bytes description; it will mostly always be 1, 2, or 4:
> > bytes Number of bytes per cell (1, 2, 4)
AR:
> I've made first:
>
> grdinfo 38n34n9w2w.grd
>
> 38n34n9w2w.grd: Title: GEBCO One Minute Grid
> 38n34n9w2w.grd: Command: 1.02
> 38n34n9w2w.grd: Remark:
> 38n34n9w2w.grd: Normal node registration used
> 38n34n9w2w.grd: grdfile format: cs (# 8)
> 38n34n9w2w.grd: x_min: -9 x_max: -2 x_inc: 0.0166667 name: user_x_unit
>
> nx: 421
> 38n34n9w2w.grd: y_min: 34 y_max: 38 y_inc: 0.0166667 name: user_y_unit
>
> ny: 241
> 38n34n9w2w.grd: z_min: -4060 z_max: 3110 name: user_z_unit
> 38n34n9w2w.grd: scale_factor: 1 add_offset: 0
>
> So from the nx and ny values above, in GRASS I've tried:
>
> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati
> north=38 south=34 east=-2 west=-9 rows=241 cols=421
>
> ATENCIÓN: Bytes do not match File size
> ATENCIÓN: File Size 203536 ... Total Bytes 101461
> ATENCIÓN: Try bytes=2 or adjusting input parameters
>
> So, again:
>
> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati
> north=38 south=34 east=-2 west=-9 rows=241 cols=421 bytes=2
> ATENCIÓN: Bytes do not match File size
> ATENCIÓN: File Size 203536 ... Total Bytes 202922
> ATENCIÓN: Try bytes=2 or adjusting input parameters
>
> I tried with bytes=1 and bytes=4 but the same problem. The combination
> of rows, cols and bytes never match the file size: 203536
241 * 421 * 2 = 202922. Your file has 614 too many bytes. Header info?
I have the GEBCO bathy loaded into a lat/lon location here (sort of),
which I did back in Nov 2005.
Looking through the history I used this method-
Note the .jpg I used does not contain absolute depths.
The .jpg I have is 21601x10801 (1' +1), 6190902 bytes, greyscale.
gdalinfo:
Band 1 Block=21601x1 Type=Byte, ColorInterp=Gray
In a simple XY location:
r.in.gdal in=gebco_bathy.21601x10801.jpg out=gebco_bathy
r.region gebco_bathy n=90 s=-90 e=180 w=-180
g.region rast=gebco_bathy
r.out.mat in=gebco_bathy out=/tmp/grass/gebco_bathy.mat
In a Lat/Lon location:
r.in.mat /tmp/grass/gebco_bathy.mat
r.colors gebco_bathy col=grey
I may have done some adjustment in Matlab, it is too long ago to
remember. Probably I just used r.out.mat and r.in.mat to load the data
into a lat/lon location without "lat>90" type errors. The final z-scale
is 0-255, so that isn't much good for quantitative analysis. At minimum
it needs scaling. Maybe better r.region details to cover the (60*360)+1
too?
Looking at the "free download" website I give up in a sea of online
registrations and "buy the full CD here". :-/
As an alternative, the etopo2 dataset is pretty nice and includes the 2'
Smith & Sandwell satellite altimetry ocean bathymetry. (See the article in
GRASS Newsletter vol. 1)
Hamish
------------------------------
Message: 8
Date: Thu, 15 Mar 2007 14:17:52 +1300
From: Hamish
Subject: Re: [GRASS-user] ascii to dem
To: antonio rodriguez
Cc: grassuser at grass.itc.it
Message-ID: <20070315141752.155f6eaf.hamish_nospam at yahoo.com>
Content-Type: text/plain; charset=US-ASCII
antonio rodriguez wrote:
> I have imported into GRASS an ascii file (bathymetry) like this:
>
> r.in.ascii in=/home/toni/tmp/38n34n9w2w/baty2.xyz out=bati
>
> north: 38
> south: 34
> east: -2
> west: -9
> rows: 241
> cols: 421
> -9 38 -137
> -8.98333 38 -127
> -8.96667 38 -119
> -8.95 38 -112
> -8.93333 38 -101
> -8.91667 38 -81
> -8.9 38 -63
> -8.88333 38 -45
> -8.86667 38 1
> -8.85 38 8
>
> How do I transform it into a 'typical' dem map. It's to say a
> continous-aspect dem map not a dotted-aspect one?
That looks like x,y,z data, not a 2D ASCII array. r.in.ascii wants a 2D
array of z values, x,y are calculated from header. (see the example in
the help page)
Use r.in.xyz to import your data after crafting g.region settings by hand.
Hamish
------------------------------
Message: 9
Date: Thu, 15 Mar 2007 09:23:51 +0100
From: "Jose Gomez-Dans"
Subject: [GRASS-user] Datum transformations
To: grassuser at grass.itc.it
Message-ID:
<91d218430703150123t3ce96faar5feed36e3070aaed at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi!
This is a GDAL-related question, but since I am also using GRASS, here
it goes. I have a number of GeoTIFF images in UTM30N/WGS-84 format. I
want to conver the datum to European 1950 and viceversa (in EPSG
parlance, this is a transformation from 32630 to 23030, if memory
serves). This is easily accomplished with gdalwarp, but I am unable to
specify the transformation parameters for my geographic area. For
example, if I define a region in GRASS from EPSG codes, I am asked for
the EPSG code, as well as for which datum transformation I want to
use. I believe this can be set in the -towgs84 paramter in GDAL, but I
am unsure on what numbers to use for Southern Spain (in GRASS, I think
it's either datum transform option 4 or 5 for a location defined as
EPSG 23030). Can anyone point me to the file where these parameters
are stored, or some other relevant info?
Many thanks!
jose
------------------------------
_______________________________________________
grassuser mailing list
grassuser at grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
End of grassuser Digest, Vol 11, Issue 22
*****************************************
Pawan Joshi
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20070430/a0cb9892/attachment.html
More information about the grass-user
mailing list