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

[Marvin Humphrey]

Glynn,

Thank you for your detailed reply.

On Friday, January 31, 2003, at 03:08 PM, Glynn Clements 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'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?

> Or add /usr/local/bin to PATH; there are more possible ways to do this 
> than I can go into here.

I've figured this out now. Thank you for the tip.

It turns out that X11 doesn't have the same behavior as Terminal when 
logging in.  There was a long thread on this in the X11-users list from 
Apple.  One workaround is to change the /etc/csh.login file, which 
Terminal reads (but X11 doesn't), then launch X11 from Terminal: open 
/Applications/X11.app

When you do that, X11 inherits the path variable from Terminal.

It seems that I could also have set up a ~/.cshrc file, which I don't 
have right now.  But I didn't want to go there, just yet.

> From the various reports that I've seen, I suspect that using xterm
> will cause far fewer problems than the Mac's native Terminal program.

FWIW, adding /usr/X11R6/bin to the PATH hasn't seemed to make a 
difference in functionality under either Terminal or X11.  But I'm not 
doing very much yet.

>> -- Figured out how to move the drop TCLTK down menu list from behind 
>> the Mac OS header bar, by changing the location of the Dock. (a minor
>> issue)
>> -- Started to grok the GUI, including activating and selecting 
>> monitors before doing anything else.
>
> This sounds like a Mac Tcl/Tk thing.

Apparently, having an X11 app appear with it's header bar behind the 
Mac menu bar is a bug in the current Apple X11 public beta.  Other apps 
can exhibit similar behavior, including xterm.

> AFAICT, everyone who is using GRASS on OS X *isn't* a developer.;
> that's most of the problem. I suspect that we could fix most of the
> problems, if we knew *exactly* what the problems were.

Ah.

>> -- 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!

> 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...

> 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.

> I don't think that there's formal documentation; however, you can
> examine the tcltkgrass/module directory (e.g.
> /usr/local/grass5/tcltkgrass/module) to see which modules are
> available, and you can search the tcltkgrass/main/menu.tcl script to
> find out what the menu item is called.

PERFECT!  That gives me everything I need to know.

> If all you want to do is create maps, GMT[2] might be a better option.
> GRASS is primarily an analysis package, whereas GMT is oriented
> towards creating maps.
>
> [2] http://gmt.soest.hawaii.edu/

I tried GMT but I couldn't make it compile.  It stopped at the 
makefile...  I'm going to try to go with GRASS.

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.

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?

My source for the GTOPO30 data is...
http://edcdaac.usgs.gov/gtopo30/gtopo30.html

> The other issue is that tcltkgrass is simple GUI front-end that was
> created as an afterthought. The "real" UI is the command line
> interface.

Check.  I'll be learning it, then.  I'll have to, if I want to use 
r.proj!

Thanks again, Glynn.  Hopefully my reports have been of some small use 
to you, 'cause you've been a big help for me.

PS: Tip for other newbies: if you want to browse everything on your 
hard drive including all the hidden unix files via the OSX Finder, 
install Tinkertool:
http://www.bresink.de/osx/TinkerTool2.html

-- Marvin Humphrey
CD Design website: http://marvin.mrtoads.com