I must admit to feeling a bit uncomfortable with all these data import
problems I'm having, but I do read the man pages carefully before I begin
and when I have problems.
This time it's with a DRG (Digital Raster Graphic) file; a scanned image
of a 7.5-minute topographic quadrangle map. The data files are a pair: one
has the entension .TIF, the other .TWF jOnce I figured out that the filename
began with an "O" (oh) rather than a "0" (zero), r.in.tiff ran and displayed
several lines of output.
When I started a monitor and used d.rast to display the image, all I saw
was a narrow, white rectangle.
How do I determine where the problem originates?
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Making environmentally-responsible mining happen.
Rich Shepard wrote:
I must admit to feeling a bit uncomfortable with all these data import
problems I'm having, but I do read the man pages carefully before I begin
and when I have problems.
This time it's with a DRG (Digital Raster Graphic) file; a scanned image
of a 7.5-minute topographic quadrangle map. The data files are a pair: one
has the entension .TIF, the other .TWF
Do you mean .TFW?
jOnce I figured out that the filename
began with an "O" (oh) rather than a "0" (zero), r.in.tiff ran and displayed
several lines of output.
When I started a monitor and used d.rast to display the image, all I saw
was a narrow, white rectangle.
How do I determine where the problem originates?
Sounds like a region issue. If a corresponding .TFW exists, r.in.tiff
will set the region according to that file's contents. The format is
six floating-point numbers, one per line, which define an affine
transformation.
The first four describe the scale/rotation/shear part. Rotation isn't
supported, so the second and third values must be zero. The first is
the E/W resolution and the fourth is the negated N/S resolution
(presumably the TFW coordinate system has its Y-axis in the opposite
direction to that used by GRASS).
The last two are the coordinates of the centre of the top-left (North
West) pixel.
Using "g.region rast=...; g.region -p" will show the region obtained
from the .TFW file.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, 27 Jul 2001, Glynn Clements wrote:
Do you mean .TFW?
Yes.
Thanks, Glynn, I read the details on the man page.
Using "g.region rast=...; g.region -p" will show the region obtained
from the .TFW file.
Here's the contents of the .TFW file:
[rshepard@salmo coeur]$ less O40118C2.TFW
2.438400000000
0.000000000000
0.000000000000
-2.438400000000
392743.647399054025
4470852.792812664993
and here's what g.rast -p shows:
GRASS:/mnt/usr4/projects/nevada/coeur > g.region rast=rochester-drg
You have mail in /var/spool/mail/rshepard
GRASS:/mnt/usr4/projects/nevada/coeur > g.region -p
projection: 99 (State Plane)
zone: 0
datum: nad83
ellipsoid: ** unknown (default: WGS84) **
north: 4470854.01201267
south: 4454124.14961267
west: 392742.42819905
east: 405414.79299905
nsres: 2.4384
ewres: 2.4384
rows: 6861
cols: 5197
I think that the problem may be just as you say: the project directory is
in State Plane Coordinates and I think that all the SDTS data are in UTM.
The numbers report the same, but the units will be different.
What I need to do is learn how to change all my existing project data from
SPC to UTM, then try bringing in the data again. I doubt that the client or
the regulatory agencies care what projection/coordinate system/datum is
used.
Perhaps r.proj will work within a single directory to change everything.
We'll see. 
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Making environmentally-responsible mining happen.