[GRASSLIST:5424] Newbie tries OS X port

GRASS GRASS user
,
1

Greetings,

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.

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

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? 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"
-- when I try to run r.in.gdal, the terminal returns "r.in.gdal: Command not found."
-- 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.
-- 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.
-- 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.

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?

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

2

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@virgin.net>

3

Le samedi, 1 fév 2003, à 00:08 Europe/Paris, Glynn Clements a écrit :

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.

Yes it is a Unix like, it is a FreeBSD Kernel. But all the X11 specific components are not installed because by default Mac OS X doesn't use X11 but its own window manager, Quartz Extreme. You need to add it and its libraries.
Grass need a bit of unix knowledge to be installed freely without buying the CD on OpenOSX.com

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.

I think Mesa hasn't been installed. You need to compile it, I have a version if you want.

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

For me, it works in both xterm and terminal.

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

Yes you can. For me Grass is in /Applications.

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

Yes the TCL/TK for jaguar wasn't supported before this patch because it was recent.

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.

You may need to install a lot of other libraries to get it to work as explained at the end of the Mac OS page.

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

I think libjpeg wasn't installed.

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.

The same, I think Gdal is not installed. The problem is that I can't compile neither 1.1.7 neither 1.1.8. If somebody could help me...

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

r.proj is not available in the GUI. :frowning:
Anyhow, it is available via the command line.

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

It is also maybe because FFTW and netpbm are missing.

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.

I think you should purchase the CD at www.openosx.org because all is already set up to work, you have nothing to do. There's also a book on this site which explain how to use Grass.

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

A. Gillaizeau.

4

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

5

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@virgin.net>

6

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

-----Original Message-----
From: owner-GRASSLIST@baylor.edu [mailto:owner-GRASSLIST@baylor.edu]On
Behalf Of Glynn Clements
Sent: Saturday, February 01, 2003 7:23 PM
To: Marvin Humphrey
Cc: GRASSLIST@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@virgin.net>

7

geogratis.cgdi.gc.ca

Marvin Humphrey [marvin@rectangular.com] wrote:

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

--
                                   covetousness is an aerobic activity

8

On Saturday, February 1, 2003, at 07:23 PM, Glynn Clements wrote:

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.

[snip]

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

So far, few things are going kablooey. Many of the modules I need don't have GUIs anyway. I think I'll stick with the version I got from Apple for now, unless I start uncovering more nasties...

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.

It's a sign of good programming that the GRASS doesn't choke on unfamiliar fields in an extensible format. Kudos to both you and the people who made that TIFF. (IME in audio, extensible formats are not necessarily handled well...)

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.

Very good. This is my next step.

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.

I found national boundary files for the entire world from the CDC...

http://www.cdc.gov/epiinfo/EIshape.htm
http://www.cdc.gov/epiinfo/eihlgeog.htm

They're in .shp format -- I was able to get them to Illustrator through a multistep process:

v.in.shape --> v.out.ascii --> v.export

Illustrator can grok a DXF file, so that's the magic inter-application link. When I tried to skip the v.out.ascii step, GRASS hung during v.export -- apparently it doesn't like trying to export an ascii file from an internal binary format.

The resulting DXF output appeared to line up well in Illustrator with the GTOPO30, so I suppose they're using the same equidistant cylindrical projection.

There's a zillion sources for this data, and a zillion formats! Maybe if I'm lucky I can find another source that has highways and cities as well as political boundaries...

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

9

I'm trying to work on some issues with v.digit. I see a lot of debugging
code in the source files that seems to key off of a "DEBUG" environment
variable. Does anyone know what I have to do to enable debugging besides
setting "DEBUG=TRUE; export DEBUG" ? It tried that but can't see any effect.

10

On Fri, Feb 21, 2003 at 06:21:48PM -0800, Chris Heg wrote:

I'm trying to work on some issues with v.digit. I see a lot of debugging
code in the source files that seems to key off of a "DEBUG" environment
variable. Does anyone know what I have to do to enable debugging besides
setting "DEBUG=TRUE; export DEBUG" ? It tried that but can't see any effect.

It's a compile time variable:

$ cd src/mapdev/v.digit
$ editor Gmakefile
<change>
EXTRA_CFLAGS = $(DIGITFLAGS) $(USE_FTIME) $(INCTRANS)
<to>
EXTRA_CFLAGS = $(DIGITFLAGS) $(USE_FTIME) $(INCTRANS) -DDEBUG=1
<done>
$ rm -rf OBJ.<architechute>
$ gmake5

No guarantee that the debugging code doesn't cause erroneous
execution...

--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

11

----- Original Message -----
From: "Eric G. Miller" <egm2@jps.net>
To: <GRASSLIST@baylor.edu>
Sent: Saturday, February 22, 2003 10:35 AM
Subject: [GRASSLIST:5640] Re: v.digit debug mode

It's a compile time variable:

Of course, it's a compiler switch not an environment variable. uhh I knew
that...
Thanks.