[GRASSLIST:5443] Re: Newbie tries OS X port

[Terry Whin-Yates]

Somebody please get me off this list.  I have tried everything and nothing
works.

-----Original Message-----
From: owner-GRASSLIST at baylor.edu [mailto:owner-GRASSLIST at baylor.edu]On
Behalf Of Glynn Clements
Sent: Saturday, February 01, 2003 7:23 PM
To: Marvin Humphrey
Cc: GRASSLIST at baylor.edu
Subject: [GRASSLIST:5442] Re: Newbie tries OS X port



Marvin Humphrey wrote:

> > Warning: Tcl/Tk supports three distinct platforms: Unix/X11, Windows,
> > and Mac. The tcltkgrass interface *might* work with the Mac version,
> > but NVIZ definitely needs a Unix/X11 version of Tcl/Tk. It also needs
> > a Unix/X11 version of OpenGL.
>
> So the version of Tcl/Tk I got off the Apple site might not work, hmm?
>
> http://www.apple.com/downloads/macosx/unix_open_source/tcltk.html

It might; the "unix_open_source" bit suggests that it may be either a
Unix version or a hybrid Unix/Mac version, rather than a "pure" Mac
version.

> It's the "Batties Included" Aqua version. Instead, I would need to find
> one off of this page, I assume...
>
> http://sourceforge.net/project/showfiles.php?group_id=10894
>
> Is there one that's recommended?

If Apple's Tcl/Tk package doesn't work, the "safe" solution is to
download the Tcl/Tk source code and build it yourself (following the
Unix build instructions).

> >> -- using r.in.tiff, I get the error message "dyld: r.in.tiff can't
> >> open library: libtiff.dylib  (No such file or directory, errno = 2)
> >> Trace/BPT trap"
> >
> > Did you need to use --with-tiff-libs=... when configuring? Is
> > libtiff.dylib in a "standard" directory? (On Unix, this would be /lib
> > or /usr/lib, but (AFAIK) MacOS X decided to be different).
>
> I found it in /Library/Tcl/Img1.2/libtiff.dylib
>
> I've copied it to /usr/lib/libtiff.dylib
>
> Now when I try to run...
>
> r.in.tiff input=Users/marvinhumphrey/Desktop/logos.tiff output=dclogos2
>
> ... I get these error messages:
>
> /Users/marvinhumphrey/Desktop/logos.tiff: Warning, unknown field with
> tag 700 (0x2bc) ignored.
> /Users/marvinhumphrey/Desktop/logos.tiff: Warning, unknown field with
> tag 34665 (0x8769) ignored.
>
> But... IT WORKS!

The TIFF format is extensible, and it's not uncommon for certain
packages to add their own extensions (e.g. storing application
settings in the image). Warnings regarding unknown extensions are
usually harmless.

> > By default, r.in.gdal tries to load the GDAL library dynamically (like
> > a "plug-in"). I suspect that this doesn't work on a Mac; using the
> > --with-gdal configure switch may fix this.
>
> How do I do use the --with-gdal configure switch?  Wouldn't that
> require a recompile?  I installed from the binaries...

It would require a re-compile. Or, rather, whoever compiled it should
have used this switch; if they didn't, r.in.gdal would probably fail
to compile, which would explain the "command not found" error.

Or maybe they just couldn't get either r.in.gdal or GDAL itself to
compile on the Mac (actually, this rings a bell; I have made some
changes to r.in.gdal to improve portability; they don't appear to have
made it into 5.0.1 though).

> > The one factor which seems to bite people when importing rasters is
> > that, by default, the map is positioned at the origin (i.e. (0,0)) in
> > the projection's coordinate system, which results in it being far
> > outside of the current region (use r.info and g.region to confirm
> > this). You can use r.region or r.support to position the raster (you
> > need to know the bounds of the raster; this information *isn't* stored
> > in the DEM).
>
> Eureka!   I've got both tiffs and GTOPO30 data importing successfully
> now.  Exporting to tiff, too.  The imported tiff was, indeed, outside
> the defined region.
>
> Using g.region.sh from the GUI did the trick.

That's OK for a test case. For real-world use, it usually needs to be
the other way around; you have to move the imported map to its correct
geographical location with r.region or r.support.

> What I need GRASS to do at a minimum is reproject GTOPO30 data, then
> export a tiff.  I'm almost there, I just need to grok r.proj.

OK. GTOPO30 is in a lat-lon coordinate system. Basically you need a
lat-lon location plus a location which uses your chosen coordinate
system (UTM, state-plane etc).

First, import the GTOPO30 data into the lat-lon location with
r.in.bin, providing the correct parameters, e.g.

r.in.bin bytes=2 input=w020n90.dem output=w020n90 title=w020n90 west=-20
north=90 east=20 south=40 r=6000 c=4800 anull=-9999

Then, exit GRASS and re-start it, selecting the destination location.
Set the correct region[1] and resolution with g.region, then project
the data with e.g.

r.proj input=w020n90 location=latlon method=cubic

Optionally use d.rast to check that you got what you expected, then
finally export it as a TIFF with r.out.tiff.

[1] This requires some knowledge of the coordinate system. If you have
no idea as to the correct destination coordinates, you can use m.proj
to project individual lat-lon coordinates.

> A bonus would be to get locations of national and provincial
> boundaries, major highways, etc, in some sort of vector format, overlay
> that so it syncs with the raster data, then export to DXF... manipulate
> raster data in Photoshop, MacDEM, or something similar, import the nice
> pretty raster file into Illustrator along with the DXF, shake well,
> export to JPG, et voila!  Hundreds of web maps for my client.
>
> Does anyone know of a source for such vector data?

There are some links on the GRASS site. However, the quality of the
data (in terms of what you end up with inside GRASS) can vary. Some of
the proprietary formats have been implemented using a fair amount of
trial-and-error.

Also, if you need to get data sets to line up accurately, it becomes
important to know the ellipse and datum.

--
Glynn Clements <glynn.clements at virgin.net>