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

[Glynn Clements]

Marvin Humphrey wrote:

> I spent several hours yesterday trying to install and configure GRASS 
> for OS X Jaguar (10.2.3), and I'm starting to wonder if I haven't 
> bitten off more than I can chew.  At every step of the way, there seem 
> to be bugs and tweaky interfaces requiring very precise maneuvering.  
> If I had more experience with unix, I think I would be in better shape 
> -- the bulk of my experience is with classic Mac.  I'm used to 
> troubleshooting (I was in prepress for two years, and I've done beta 
> testing for CD burning software), but maybe GRASS is just not at a 
> stage where someone of my level of experience can come in and use it 
> efficiently?  I'm not a professional cartographer or programmer, I'm a 
> print designer and audio engineer who's making a career move to web 
> design.

AFAICT, the problem is that MacOS X isn't quite as Unix-like as some
people seem to claim.

Basically, GRASS runs on Unix and Unix-like[1] systems. Getting it to
work on MacOS X basically comes down to getting MacOS X to behave in a
sufficiently Unix-like manner.

[1] e.g. Cygwin and, with some tweaking, MacOS X.

> So far, I've...
> 
> -- Installed the Apple distribution of X11.  It's officially a public 
> beta, but the OpenOSX folks seem to think it's alright.
> -- Installed a more recent version of TCLTK than comes from the GRASS 
> download page.  I got the 8.4.1 version from Apple, figuring that was 
> the most reliable source for current OS X compatibility.

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.

> -- Installed the GRASS binary and applied the patch for TCLTK, though I 
> haven't yet applied the patch for NVIZ.
> -- Installed the Spearfish and g51test-9 sample datasets.
> -- Found that typing 'grass5' to start the program doesn't work, even 
> after running the suggested script.  Discovered the workaround of 
> typing this instead: sh /usr/local/bin/grass5

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

> -- Figured out how to launch grass from X11's Xterm, rather than 
> Terminal, allowing me not only to start GRASS, but also to start the 
> monitors.  (I figured this out by making a connection between the word 
> xterm in the error messages and the fact that I'd seen that word when 
> launching X11.  Yes, I'm inexperienced.)

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

> -- Discovered that installing GRASS anywhere other than /usr/local/ 
> causes GRASS to not find required files.  (And therefore, uninstalled 
> and reinstalled where GRASS wanted to go.)

The only file which has a hardcoded path is the "grass5" script
itself:

	# Set the GISBASE variable
	GISBASE=/opt/grass5
	export GISBASE

You can put the rest of GRASS wherever you like, so long as you change
that line in the grass5 script.

> -- Solved the missing OSX-BG.gif problem by making my own gif and 
> putting it in the right directory.
> -- Solved the "window name 'frameosx_BG' already exists in parent" 
> problem by installing a patch from OpenOSX, posted two days ago.  This 
> was dicey, but they seemed to be using the same components I'd 
> installed, so I tried it and the problem did go away.
> -- 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.

> At this point, I can launch GRASS and its GUI, and keep playing around 
> without having it crash too often.  But now that I'm getting into the 
> nitty gritty of the program I am finding out that the debugging and 
> configuration-massaging may be far from over.  The startup bugs that 
> I've experienced, I've found documented in both the archives of this 
> listserv and the bug/wish list, so I'm not alone... but who is using 
> the GRASS OS X port who isn't a developer? 

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.

>  The "window name 
> 'frameosx_BG' already exists in parent" problem seems like a fatal 
> flaw, at least for anyone who wanted to use the GUI, and the patch just 
> came online a couple days ago!  Anyway, now I've got a new list of 
> unresolved issues...
> 
> -- 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).

If libtiff.dylib exists but is in a non-standard location, workarounds
include creating a symlink or copying the library, or setting an
appropriate environment variable (on Solaris and Linux, it's
LD_LIBRARY_PATH; I have a vague recollection that MacOS X uses DYLD_*
instead, although I could be misremembering).

> -- when I try to run r.in.gdal, the terminal returns "r.in.gdal: 
> Command not found."

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.

> -- using r.in.bin from the GUI, I can't quite manage to get some 
> GTOPO30 data to load. I've gradually begun to figure out what numbers 
> need to go where, and I finally saw it take a while to chew and watched 
> the percentages slowly rise... but it still generated a blank file. 
> This is presumably a user issue, but the interface isn't too much help 
> for me as I attempt to escape my ignorance.

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

> -- um, is there a list anywhere of which modules actually are available 
> for the GUI?  Eventually, I need to use r.proj.  I can't find it there 
> yet, but the names don't correspond.  I suppose I could launch every 
> one to see what it does, and check out the man pages, but it would be 
> neat if that documentation existed somewhere already.

r.proj doesn't appear to be available via tcltkgrass.

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.

> -- I frequently get a Wish lockup when selecting a monitor.
> 
> Ultimately, I plan to make a few hundred maps for a client's website.  
> Maybe 3-10 for each US state, and a similar number for European 
> countries.  I'll be augmenting these in Photoshop and Illustrator.  I'm 
> planning on using the GTOPO30 dataset, but it needs to be reprojected.  
> The purchase of GeoCart is hard to justify for this limited use, 
> especially since the Mapthematics website doesn't even mention OS X at 
> all.

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/

> These are all simple starter issues, too -- I'm just trying to get 
> tiffs into this program!  Once I solve them, am I going to find that 
> all the processing modules present similar challenges?  I've made some 
> pretty sketchy systems work in my day, but I've got to ask... is this 
> going to be worth it?  I had thought that if I learned the basics of 
> GRASS, I could get this project done, and I might find the familiarity 
> gleaned from it of use in the future.  But now I'm thinking that the 
> initial learning curve may be too steep, what with the bugs and the 
> quirky interface catering to the power user over the newbie.  Comments?

I suspect that most of your problems relate to MacOS X, although the
import issue (import/draw produces a blank screen) is a common newbie
problem.

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.

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