<html>
<head>
<title>The Geographic Information Systems: GRASS Mini-HOWTO</title>
</head>
<body>
<center><h4>This document is not subject to copyright. See section 9 below.
<br>Version 1.0: 13 November 1997</h4>
<br><h1>The GIS-GRASS mini-HOWTO</h1>
<br><h4>by David A. Hastings
<br>U. S. Department of Commerce
<br>National Oceanic and Atmospheric Administration
<br>National Geophysical Data Center
<br>Boulder CO 80303
<br>dah@ngdc.noaa.gov</h4></center>
<p><b>Summary:</b> This document describes how to acquire, install and configure a
powerful scientific public-domain Geographic Information System (GIS):
the Geographic Resources Analysis Support System (GRASS). It provides
information on other resources for learning more about GRASS, GIS in
general, for acquiring data, etc.
<p>This document also encourages the Linux community to consider enhancing
this software as a major application of UNIX/Linux. ("When will Linux
become bundled with public domain or Linux Public License 'killer
aps'"?) For more on this topic, see Section 8 below.
<center><h2>Contents</h2></center>
<ol>
<li><b>What is a GIS?
<li>What is GRASS?
<li>A Brief History of GRASS
<ol>
<li>A Re-Invogorated GRASS Management Model
<li>Continued Assessment of Future GRASS Management
</ol>
<li>System Requirements for GRASS
<li>How to Acquire GRASS
<li>How to Get GRASS Running on Your Linux-based Computer.
<li>Web-based Support for GRASS (and for GIS Matters in General)
<li>The Future of GRASS?
<li>Copyright Notice, and Notice on Support of this Document
<li>References</b>
</ol>
<p><b>Appendix A: Acquisition/Installation of GRASS4.1.3 Binaries
<br>Appendix B: Acquisition/Installation of GRASS4.1.5 Binaries
<br>Appendix C: Acquisition/Compilation of GRASS 4.1.x and 4.2 Source Code
<br>Appendix D: If you plan to enhance any part of GRASS, read this first!
<br>Appendix E: Example Linux versions of some critical GRASS files.
</b>
<hr>
<center><h3>1. What is a GIS?</h3></center>
<p>There are many ways to describe a Geographic Information System. Here
are three working definitions (from David A. Hastings, 1992, Geographic
Information Systems: A Tool for Geoscience Analysis and Interpretation):
<ol>
<li>(The minimal definition): A GIS is a hardware/software system
for the storage, management, and (with hardcopy or screen
graphic) selective retrieval capabilities of georeferenced data.
Definitions like this one are often used by vendors and users of
vector-only GIS, whose objective is sophisticated management and
output of cartographic data.
<li>(A parallel definition): A GIS is a hardware/software system for
managing and displaying spatial data. It is similar to a
traditional Data Base Management System, where we now think in
<u>spatial</u> rather than in tabular terms, and where the
"report writer" now allows output of maps as well as of tables
and numbers. Thus we can consider a GIS a "spatial DBMS" as
opposed to traditional "tabular DBMSs." Few people use this
definition, but it might help to explain GIS to a DBMS user.
<li>(A more aggressive definition): A GIS is a system of hardware,
software, and data that facilitates the development,
enhancement, modeling, and display of multivariate (e.g.
multilayered) spatially referenced data. It performs some
analytical functions itself, and by its analysis, selective
retrieval and display capabilities, helps the user to further
analyze and interpret the data. Properly configured, the GIS
can model (e.g. synthetically recreate) a feature or phenomenon
as a function of other features or phenomena which may be
related - where all features or phenomena are represented
(characterized) by spatial and related tabular data. The
analytical objectives described here are sometimes controversial
- and often given lip service by cartographic GIS specialists
who have not yet seen what can be accomplished scientifically by
a select few GISs that go beyond cartographic approaches.
<li>Another definition can be found at <a href="http://www.geo.ed.ac.uk/home/research/whatisgis.html">http://www.geo.ed.ac.uk/home/research/whatisgis.html at the University of
Edinburgh</a>
</ol>
<center><h3>2. What is GRASS?</h3></center>
<p>GRASS (Geographic Resources Analysis Support System) is a public domain
raster based GIS, vector GIS, image processing system, and graphics
production system. Created by the US Army Corps of Engineers,
Constriction Engineering Research Laboratory (USA/CERL) and enhanced by
many others, it is used extensively at government offices, universities
and commercial organizations throughout the world. It is written mostly
in C for various UNIX based machines. Linux is one of its more robust
implementations.
<p>GRASS contains over 40 programs to render images on monitor and paper;
over 60 raster manipulation programs; over 30 vector manipulation
programs; nearly 30 multi-spectral image processing manipulation
programs; 16 data management programs; and 6 point file management
programs.
<p>GRASS' strengths lie in several fields. The simple user interface makes
it an ideal platform for those learning about GIS for the first time.
Users wishing to write their own code can do so by examining existing
source code, interfacing with the documented GIS libraries, and by using
the GRASS Programmers' Manual. This allows more sophisticated
functionality to be fully integrated within GRASS.
<p>Other strengths include GRASS' pioneering of mixed resolutions in a data
base, mixed geographic coverage areas in a data base, raster image
compression techniques via run-length encoding and reclassification
lookup tables, GRASS' rescaling of display images on the fly to fill the
display screen, plus its fundamental design criterion of powerful
computer-assisted scientific analysis of environmental issues (as
opposed to merely going for intricate cartographic output of relatively
simple processes).
<p>GRASS is usually supplied as free, non-copyright source code to be
compiled on host machines. Some compiled binaries are also easily
obtainable at no cost via the Internet. It runs on a variety of UNIX
platforms.
<p>(Copied from Project Assist
<a href="http://www.geog.le.ac.uk/assist/grass">Intro to GRASS:http://www.geog.le.ac.uk/assist/grass</a>)
<center><h3>3. A Brief History of GRASS</h3></center>
<p>In the early 1980s the U. S. Army Corps of Engineers' Construction
Engineering Research Laboratory (USA/CERL) in Champaign, Illinois, began
to explore the possibilities of using Geographic Information Systems to
conduct environmental research, assessments, monitoring and management
of lands under the stewardship of the U. S. Department of Defense. Part
of the motivation for this action was new responsibility for the
environment encoded into the National Environmental Policy Act of the
late 1970s.
<p>Bill Goran of USA/CERL conducted a survey of available GISs, assuming
that he could find several systems capable of environmental analysis,
from which he could select one or more to recommend for use by CERL and
perhaps others in the Department of Defense. However, he was surprised
to find no GIS that satisfied his needs. What started as a selection
process turned into a design exercise for his own GIS development
program.
<p>USA/CERL hired several programmers, and began by writing a hybrid
raster-vector GIS for the VAX UNIX environment. This made the team one
of the first to seriously develop GIS for UNIX. Though they still faced
challenges with different versions of UNIX, they developed procedures of
coding in ANSI standard UNIX, avoiding "tweaking" the code toward any
particular vendor-specific flavor of UNIX.
<p>GRASS developed a programming style characterized by:
<ul>
<li>Use of UNIX libraries where possible, plus the creation of GRASS
libraries for repeated GIS-specific acts such as opening raster
files that might be compressed (by run-length encoding) or not.
<li>The ability to handle both major GIS data types: raster and vector.
<li>The favoring of raster data processing, as scientific analysis was
easier to encode with raster (than for vector) data models.
<li>The ability to handle raster grids of mixed grid sizes in the same
data base. This was a departure from raster's image processing
tradition of requiring identical (and perfectly registered) grid
cell arrays in each and every data layer.
<li>The ability to handle raster grids with different areas of
coverage. Again, this was a departure from raster tradition of
having all grids be identical in geographic coverage.
<li>The ability to run-length encode raster data files, in order to
greatly reduce file sizes of most files.
<li>The separate structure of reclassification files. Such files
merely contained a look-up table noting the previous and new
classes. This is MUCH more compact than replicating the original
grid with different numerical values. A reclassified file of a
100x100 km square area of 10 metre grid cells would be a few
hundred bytes, rather than 100 megabytes of uncompressed 8-bit
raster data.
<li>The acceptance of de-facto standard data models. While competitors
created cumbersome (and in many cases secretive) data formats,
GRASS accepted the de-facto standard Digital Line Graph vector
format and unheaded binary raster grid format. GRASS later
abandoned DLG as its internal vector file format, and let its
raster format evolve. However, DLG and the unheaded binary raster
grid are still routinely handled formats for GRASS, and its new
formats are as open as its previous ones.
<li>GRASS code was managed in several directories. Initial
contributions were placed in the src.contrib directory. More solid
code was moved to the src.alpha directory. After remaining in the
src.alpha for one full release cycle, the code, with resultant bug
fixes, moved to the most honorable level, the src directory.
</ul>
<p>GRASS was overseen by three levels of oversight committees. USA/CERL
kept the ultimate responsibility for GRASS. It implemented most GRASS
development, and carried out the day-to-day management of GRASS testing
and release. The GRASS Interagency Steering Committee (GIASC),
comprised of other Federal agencies, met semi-annually to review
development progress, and evaluate future directions for GRASS.
(Academic and commercial participants in GRASS also attended GIASC
meetings; only part of each meeting was "Federal-Agencies-only." GRASS
eventually became nominally and officially a "product" of the GIASC,
though everyone recognized USA/CERL's leadership role. The GRASS
Military Steering Committee met periodically to review the progress of
GRASS in serving its original intent: meeting the Department of
Defense's needs to evaluate and manage the environment of military
lands.
<p>The public interacted with CERL and GIASC through USA/CERL's GRASS
Information Center. GRASS Beta testing was very widespread, and quite
intensive for the leading users of GRASS. Several leading users, such
as the National Park Service and the Soil Conservation Service, selected
GRASS as its prime or only GIS. They made significant commitments to
enhance and test GRASS, yet considered this investment well worth their
while. They said that they had more influence over the direction of
GRASS than they would over any known alternative system. They also felt
that, despite their major efforts and expenses in supporting GRASS, they
had a bargain in relevant power for the dollar.
<p>Several universities adopted GRASS as an important training and research
environment. Many conducted short-courses for the public, in addition
to using GRASS in their own curricula. Examples of such leading
academic users of GRASS are Central Washington University, The
University of Arkansas, Texas A & M University, The University of
California at Berkeley, and Rutgers University.
<p>Though GRASS received some criticism (some say) for being so good and so
public, it was also reputedly borrowed from liberally by some developers
of other systems. Though the first group might have viewed it as unfair
competition, the second group may have noted that it was not copyright,
and was a valuable testbed for GIS concepts. GRASS received an award
from the Urban and Regional Information Systems Association (URISA) for
quality software in 1988.
<p>As CERL and GRASS evolved through the late 1980s and early 1990s, CERL
attempted to cut overhead costs associated with supporting the public
domain version. It created and initially funded the Open GRASS
Foundation, in cooperation with several of the leading users of GRASS.
The Open GRASS Foundation has since evolved into the Open GIS
Consortium, which is aiming for more thorough interoperability at the
data and user interface level, but appears not to be taking advantage of
the major open GIS testbed (GRASS).
<p>In 1996 USA/CERL, just before beginning the beta testing for GRASS
version 5.0, announced that it was formally withdrawing support to the
public. USA/CERL announced agreements with several commercial GISs, and
agreed to provide encouragement to commercialization of GRASS. One
result of this is <a href="http://www.las.com/grassland/">GRASSLANDS:http://www.las.com/grassland/</a>,
a commercial adaptation of much of GRASS. Another result is a migration of
several former GRASS users to COTS (Commercial Off-The-Shelf) GISs.
However, GRASS' anonymous ftp site contains many enhancements to the
last full version 4.1 release of GRASS. Many organizations still use
GRASS feeling that, despite the lack of a major release in five years,
GRASS still leads the pack in many areas.
<center><h4>3.1 A Re-Invogorated GRASS Management Model</h4></center>
<p>In late 1997, a group at Baylor University took the lead in developing a
new Website for GRASS. This quickly developing Website contains GRASS 4.1
source code and Sun Solaris binaries, GRASS 4.1 documentation, and an on-
line manual. By November 1997 this site posted the first version of GRASS
4.2 source code and binaries currently for Sun Solaris) with Linux and
Windows NT under consideration). GRASS 4.2 incorporates several
enhancements from the CERL website, plus some of Baylor's own
enhancements. Documentation for GRASS 4.2 is appearing; the group
encourages cooperation in further development of GRASS, and is looking for
partners. It hopes to use increased use of the World Wide Web in
developing and managing GRASS. GRASS 5 development and compilation is
underway. The site also links to the Blackland GRASS site at Texas A&M
University, for those desiring very inexpensive access to GRASS for
Windows 95.
<center><h4>3.2 Continued Assessment of Future GRASS Management</h4></center>
<p>Note: An ad-hoc group (which includes myself) is exploring the basic issue
of continued, reconfigured, yea perhaps increased, value of GRASS as a
public test-bed for GIS technology. It is exploring shepherding the
testing and release of GRASS5.0, and exploring possibilities for a more
distributed management model for GRASS design and development. It is
exploring the universe of public domain spatial data processing software
(including geographic information and image processing systems), and
perhaps tabular data base management systems. How can such knowledge be
(1) optimized as an open, public test bed for such technology and (2)
better used by the public? Might this involve a Linux management model,
perhaps? See Section 8 for more discussion on this topic.
<center><h3>4. System Requirements for GRASS</h3></center>
<p>Minimum requirements include:
<ul>
<li>8 Mbytes of memory (of course, more is better..)
<li>100 Mbytes of free disk space
<ul>
<li>~40 mb for executables,
<li>~40 mb for source code (which you can ignore if you merely install the Linux binaries)
<li>~? for data (the veritable bottomless pit can be filled with data, if you so choose)
</ul>
</ul>
<br>GRASS runs on Linux kernel versions as old as 1.2.13 (see more
information in the appendices for various specific binaries).
<br>GRASS will run in text mode. However, for displays of data, you will
need X. If you are still running a version of X, it will probably
work with GRASS.
<p>If you find any other hardware/OS requirements that should be mentioned, please let me know!
<center><h3>5. How to Acquire GRASS</h3></center>
<p>GRASS used to be available on tape from various companies that signed
distribution agreements with USA/CERL. These companies usually
supported specific platform environments, such as Masscomp, Sun, DEC,
Hewlett Packard, IBM (risc), PC (running some flavor of UNIX), and
Macintosh (running AUX). Until recently, the flavors of UNIX working on
PCs generally were too low-end, or required too much added programming
support (e.g. programming drivers for high-end graphics boards like the
Number Nine boards of several years back) to be stable or complete.
However, with robust systems like Linux, this problem is history.
Similarly, few people acquire GRASS on tape, though a few do on CD-ROM.
<p>The main way to acquire GRASS is to get it via anonymous ftp from:
<p><b>1. The new site at <a href="http://www.baylor.edu/~grass">Baylor University:http://www.baylor.edu/~grass</a></b>
<p>As of the date of this version of the mini-HOWTO, Baylor has source code
for GRASS 4.1 and 4.2, as well as Sun Solaris compiled binaries.
Blackland GRASS for Windows 95/NT is linked to from this site. Baylor is
considering its own Linux and Windows NT binaries, as well. You should be
able to compile the Baylor source code under Linux yourself, using
information in this mini-HOWTO.
<p><b>2. The traditional site at <a href="http://www.cecer.army.mil/grass">USA/CERL:http://www.cecer.army.mil/grass</a></b>, or from mirrors cited at USA/CERL's
website:
<p>The ftp location is:
<p><b>moon.cecer.army.mil</b>
<p>Appendix A describes how to acquire and install GRASS4.13 compiled
binaries from USA/CERL. (See section 6 before installing GRASS!)
<p>Appendix B describes how to acquire and install GRASS4.15 compiled
binaries from USA/CERL. (See section 6 before installing GRASS!)
<p>Appendix C describes how to acquire and compile GRASS4.14 and GRASS4.15
source code from USA/CERL, as well as GRASS4.2 source code from Baylor
University. (See section 6 before installing GRASS!)
<p>Linux distribution developers! Might you be interested in including
GRASS with your distribution? Remember, GRASS source code is in the
completely unrestricted, copyright-free, public domain. Your
distribution might be more valuable if it contained source code and/or
compiled binaries for GRASS.
<center><h3>6. How to Get GRASS Running on Your Linux-based Computer.</h3></center>
<p>Appendices A, B, and C describe how to acquire and install GRASS.
Before actually installing GRASS, you will have to decide where to put
three parts of the system:
<ol>
<li>The GRASS binaries, source code (if you install this), man pages,
documentation, and the like. Many folks put this stuff off
/usr/local (e.g. /usr/local/grass/bin, /usr/local/grass/src).
<li>The GRASS executable and gmake utilities. Some folks put this
stuff off /usr/local (e.g. /usr/local/grass/grass4.1 and gmake4.1
or /usr/local/bin/grass4.1 and gmake4.1).
<li>The GRASS data directories. These can go anywhere, as they are
specified in configuration files.
<p>I have used a different scheme for a decade. As GRASS code, binaries,
and the like (except data owned by users) are all owned by the special
user "grass" I don't want this stuff to get spread around my system. I
create a new directory (usually on a separate file system) called /user,
and put all my GRASS stuff below this. For example:
<pre>
/user/grass4.1/bin (I usually put grass4.1 and gmake4.1 here...)
/data
/dev
/etc
/man
/src
/src.alpha
/src.contrib
</pre>
<p>I'm currently building a GRASS5.0 site, which then goes under:
<pre>
/user/grass5/bin
/data (some GRASS5 data formats have changed...)
/dev
/etc
</pre>
<p>The GRASS Installation Guide (described in Section 10 and in Appendix C)
is useful for getting GRASS running, even if you merely install the
binaries as described in Appendices A and B. Please don't overlook one
important detail: Most GRASS installations separate user from software
manager accounts and UNIX permissions. You should create a "grass" (the
quotes here are for emphasis, and should not be part of the actual user
userid) user account on your workstation. All installation and
configuration of grass should be done by user "grass". Untar (or
un"cpio" files, run setup configuration utilities, run Gmakefiles (GRASS
versions of makefiles), and edit configuration files as user "grass."
Then only RARELY run GRASS as user "grass." (I only run GRASS as user
"grass" when I am making archival data files in the PERMANENT mapset.)
This is done for much the same reason as not running user software as
user "root". YOU CAN DO TOO MUCH DAMAGE AS USER "grass"!
<p>Beyond the instructions in these appendices, and information in the
GRASS Installation Guide, you have some additional housekeeping to do,
such as developing a data base. You can acquire sample data bases from
USA/CERL (directory pub/grass/grass4.1/data at anonymous "ftp
moon.cecer.army.mil"), start from scratch following instructions in the
GRASS Programmer's Manual (and, to a lesser degree, buried in the
functional descriptions of the GRASS User's Reference Manual).
<p>I personally recommend that you start with the Spearfish and Global
databases available from USA/CERL:
<ol>
<li>The Spearfish data base covers two 7.5 minute topographic sheets in
the northern Black Hills of South Dakota, USA. It is in the
Universal Transverse Mercator Projection. It was originally
created by Larry Batten (now of the Environmental Systems Research
Institute's office in Boulder, Colorado) while he was with the U.
S. Geological Survey's EROS Data Center in South Dakota. The data
base was enhanced by USA/CERL and cooperators. It is an excellent,
and well-used (there are many training materials available for
GRASS with this data base) example of a county-scale GIS project in
the UTM projection.
<li>The Global data base was developed by Bob Lozar of USA/CERL to
prototype a latitude-longitude "projection" data base in GRASS for
global environmental study and decision support.
</ol>
<p>Starting with these two examples, you can build your own data bases in
UTM and latitude-longitude projections. (Note, many people don't call
latitude-longitude a projection. Others disagree, saying that anything
that transfers the Earth's surface to two dimensions is a projection..
We'll stay away from that debate here. Needless to say, lat-lon is
treated as other projections are by the computer program.)
<center><h3>7. Web-based Support for GRASS (and for GIS Matters in General)</h3></center>
<p>Support for a public domain program? No way, they say! Actually, as a
user of Linux, you probably know better.
<p>GRASS started by having a GRASS Information Office at USA/CERL. There
were also very active users outside USA/CERL, who provided valuable user
support. GRASS had annual users' meetings, listservers for users and
developers, etc. Companies provided value added support services on a
contractual or fee basis.
<p>Various people have developed valuable books and training materials on
GRASS. Several universities used to conduct training courses in GRASS.
I don't know how many of these are continuing. If training courses
interest you, try asking on the usenet newsgroup comp.infosystems.gis
(see below for more on this newsgroup).
<p>Valuable "books" available on the Internet are noted in the References
(Section 10).
<p>World Wide Web-based training materials, including training in GRASS,
are highlighted in the <a href="http://www.ngdc.noaa.gov/seg/tools/gis/referenc.html">CyberInstute Short Course in GIS:http://www.ngdc.noaa.gov/seg/tools/gis/referenc.html</a>
(then scan down for the link(s) to Web-based tutorials in GIS).
<p>One of the better GRASS tutorials is <a href="http://www.geog.le.ac.uk/assist/grass">Project Assist's - Intro to GRASS:http://www.geog.le.ac.uk/assist/grass</a>
<p>Other good sites:
<p><a href="http://www.csu.edu/~gishome/grass.htm">
Central Washington University was an early GRASS user and training facility:http://www.csu.edu/~gishome/grass.htm</a>
<p><a href="http://cast.uark.edu/local/hunt">
"Starting the hunt for mostly free spatial data" by Stephan Pollard:http://cast.uark.edu/local/hunt</a>
This is based at the Center for Advanced Spatial Technology of the
University of Arkansas, another early educator with GRASS.
<p><a href="http://pasture.ecn.purdue.edu/~aggrass">
Purdue University has several GRASS features:http://pasture.ecn.purdue.edu/~aggrass</a>
<p><a href="http://www.cecer.army.mil/grass/userman/main-alpha.html">
USA/CERL's online GRASS manual:http://www.cecer.army.mil/grass/userman/main-alpha.html</a>
<p><a href="http://deathstar.rutgers.edu/grassinfo.html">
Rutgers University's GRASS Information Center:http://deathstar.rutgers.edu/grassinfo.html</a>
<p><a href="http://www.regis/berkeley.edu">
The REGIS project:http://www.regis/berkeley.edu</a> at the University of California at Berkeley
as a Linux version of GRASS available via ftp, and also has
a Web-based version of GRASS called GRASSLINKS.
<p>After getting trained by the books and Web-based tutorials noted just
above, where do you turn to for specific advice???
<p>Probably the best source of support these days is usenet newsgroup
comp.infosystems.gis If you're not familiar with newsgroups, ask your
network administrator or Internet service provider.
comp.infosystems.gis contains modestly heavy traffic on such topics as
<ul>
<li>"how do I find data on this topic for this area?"
<li>"how do I convert these data for use in my Aardvark GIS?"
<li>"how do I get this function to work in my Aardvark GIS?"
<li>"which GIS can I use to solve my particular problem?"
</ul>
<p>GRASS used to be one of the top GISs discussed on this group. Traffic
in GRASS is dropping slightly, as its user community matures. However,
there are usually answers to your questions, if you post them. You
might also do a "power search" on subject:GRASS [& your own subject of
interest here?] and newsgroup:comp.infosystems.gis in
<a href="http://www.dejanews.com">DejaNews:http://www.dejanews.com</a> to see what might appear from the usenet
archives.
<center><h3>8. The Future of GRASS?</h3></center>
<p>Excellent question! Several possible answers have been thrown out:
<ol>
<li>USA/CERL's announced intention is to use GRASS and COTS (commercial
off-the-shelf software) for internal uses, to leave the GRASS
public web- and ftp-site on its system indefinitely, and to sign
cooperative research and development agreements with three
companies: (1) the Environmental Sciences Research Institute
(ESRI), (2) Intergraph, and (3) Logiciels et Applications
Scientifiques (L.A.S.) Inc. The first two agreements encouraged
the incorporation of GRASS concepts into ESRI's and Intergraph's
commercial GISs. The third encouraged the adaptation of GRASS'
concepts and code into a new commercial GIS by L.A.S. L.A.S. also
offered to encourage the continuation of a public domain GRASS, as
a viable stand-alone system and as a potential source of new ideas
and code for L.A.S.'s GRASSLAND. One observer noted that the first
two agreements might be akin to someone signing Linux over to
Microsoft. The same observer considers the experiment by/with
L.A.S. to be an interesting possibility - an attempt to keep viable
public domain and commercial versions of GRASS.
<li>Some people believe that GRASS will wither without USA/CERL's
central management. Some believe that the Open GIS Consortium will
successfully guide industry into an open architecture that will
benefit all developers and users. Others believe that OGIS' effort
will lead to a cacophony of almost similar (but not quite
interoperable) vendor-specific "standards," so the loss of GRASS as
an open development platform will be felt sorely.
<li>Some people believe that developments on some campuses and other
sites may result in those institutes keeping GRASS for awhile, but
in non-standard forms. In short, GRASS will undergo "cell
division" and lead to a cacophony of internally valuable, but
externally unused, GISs.
<li>Others hope that GRASS' previous management model under USA/CERL
has left it ready for a new model. Perhaps:
<ol>
<li>Under a new mentor, such as NASA (which needs an open,
powerful and scientific, GIS integrated with image processing
system for its Earth Observing System).
<li>Under a distributed management model... perhaps somewhat like Linux?
<li>Perhaps a bit of a hybrid? Perhaps a Web-based effort could
spawn a series of usenet discussion groups beginning with
<ul>
<li>comp.infosystems.gis.grass, and evolving to:
<li>comp.infosystems.gis.grass.academics
<li>comp.infosystems.gis.grass.publicservice
<li>comp.infosystems.gis.grass.commercialvalueadded
<li>comp.infosystems.gis.grass.commercialdistributors
<li>comp.infosystems.gis.grass.programming
<li>comp.infosystems.gis.grass.users
<li>comp.infosystems.gis.grass.centralcommittee
</ul>
Clearly the topics are a bit tongue-in-cheek. However, under this
model, a Central Committee (including representation of academic,
public service [government and nongovernmental organizations],
commercial distributors and value added firms, programmers, and
users) would guide overall grass development and testing. The
other special interest groups would serve their user communities.
Academics, for example, would involve GIS and GRASS education, but
would also try to pull GRASS development in its direction. Value
added commercial developers would serve their own interests,
including trying to pull GRASS development in a direction that
would help their businesses. Users would help each other learn
GRASS, develop workarounds to bugs, etc.
</ol>
</ol>
<p>GRASS offers considerable potential for:
<ul>
<li>Use as a scientific, as well as a traditional graphically oriented
GIS. Many GISs can make pretty maps. Many of those GISs cannot
easily perform certain scientific analytical functions as easily or
powerfully as GRASS. GRASS was designed and developed in response
to a perceived need for scientific GIS, specifically for
environmental analysis, and the environmental management/protection
of public lands. Incidentally, there is at least one Web-based
GRASS version. <a href="http://www.regis/berkeley.edu/grasslinks">GRASSLINKS:http://www.regis/berkeley.edu/grasslinks</a>, developed at the University of
California at Berkeley,
uses Web forms to submit commands to the server, which
creates .gif-based display output, places the images into pages,
and serves them up to the requester. More on that later.
<li>Education. GRASS is easier to teach and learn than some other
GISs. It is easier to modify (for those that want to learn GIS as
computer science, rather than as "geography") than most other GISs
that come without source code and treat the program as a magical
black box. And, of course, it is more affordable for the student
of GIS than many other GISs.
<li>Applications research and development. Many universities have used
GRASS. Its available source code, easy modification, easy
scriptability, etc., give it distinct advantages over some more
closed systems.
<li>Public Service. GRASS has been used as a scientific GIS for many
public service applications. There is considerable value in
continuing a robust GIS that can ba packaged with any UNIX
workstation. There is considerably more value if that UNIX
workstation universe can include Linux (but is not constrained only
to Linux).
<li>GIS research and development. For example - do you want to
experiment with a different data model? Add it to GRASS!
<li>Commercialization. This document gives contact information for a
commercial version of GRASS. That company (and perhaps others?)
may welcome your help in enhancing/supporting their product.
</ul>
<p>Who would be the Linus Torvelds equivalent in this management model?
Perhaps no single person. I have been involved in GRASS for about a
decade, when GRASS was the only GIS that satisfied my needs in
scientific data management and GIS application. Indeed, I had been a
dedicated avoider of the user-unfriendly UNIX environment until GRASS
forced me to learn it. Several senior GRASS developers are active in
GRASS-related activities and would like to see the continued vitality of
an open GRASS. It's likely that a reborn GRASS would attract a new crop
of friends. Thus the concept of a "Central Committee" to collectively
lead GRASS' transition to a more open management and development style.
<p>In short, the Linux community has an opportunity to take under its wing
a killer ap. GRASS' current public domain status is slightly different
from Linux's. However, that status could be discussed....
<p>Comments would be appreciated!
<center><h3>9. Copyright Notice, and Notice on Support of this Document</h3></center>
<p>Copyright notice:
<p>This document was prepared by a Federal civil servant in support of his
work (but mostly on his own time). It is NOT SUBJECT TO COPYRIGHT.
<p>Notice on support of this document:
<p>I believe that the contents of this document are accurate. However, if
you use this document, you accept the risks for any errors in this
document (and in any documents that are cited here).
<p>I would greatly appreciate help in correcting any errors, or in
enhancing this document. However, "my time is limited" in dealing with
this issue. Any help that you can provide, that also helps me to more
efficiently respond to your interest, is more likely to be responded to
quickly. A complaint might be appreciated, but a suggested improvement
that includes draft wording might be REALLY appreciated.
<center><h3>10. References</h3></center>
<p>For general reference material on GIS, try a very good technical
bookstore (in many cases these are campus bookstores at schools with
good GIS programs or top-notch technical or general bookstores - you
know that ones are near you..), or the following URL for the
<a href="http://www.ngdc.noaa.gov/seg/tools/gis/referenc.html">CyberInstitute Short Course on Geographic Information Systems:hQfttp://www.ngdc.noaa.gov/seg/tools/gis/referenc.html</a> (convened
by myself):
<p>Also check
<br><a href="http://www.baylor.edu/~grass">Baylor University's growing GRASS Home Page:http://www.baylor.edu/~grass</a>
<br><a href="http://www.cecer.army.mil/grass">USA/CERL's GRASS Home Page:http://www.cecer.army.mil/grass</a>
<p>For a good collection of references on GRASS, try this procedure, to
load up on reference goodies from USA/CERL:
<pre>
ftp moon.cecer.army.mil
login: anonymous
password: your email address
cd pub/grass/grass4.1/outgoing
image
get grassman.ps.Z (or grassman.txt.Z, or grassman.wp.Z)
cd ../documents/programmer/postscript
image
get progman.ps.Z
cd ../../user/postscript
image
get refman.ps.Z
cd ../..
image
get installGuide.ps.Z
bye
uncompress grassman.ps.Z
uncompress progman.ps.Z
uncompress refman.ps.Z
uncompress installGuide.ps.Z
lpr *.ps (or whatever is appropriate for your environment)
</pre>
<p>installGuide => The GRASS Installation Guide (you need this to compile GRASS source code)
<br>grassman => The GRASS Beginner's Manual (intro to GRASS)
<br>refman => The GRASS User's Reference Manual (function guide)
<br>progman => The GRASS Programmer's Manual (and administrator's guide - this is valuable for info about data formats, etc.)
<p>Browse around the ftp site noted just above, and you may find more
stuff of interest. Particularly in the pub/grass/grass4.1/documents
directory, there are tutorials on advanced GRASS functions such as
r.mapcalc (think of this as math applied to raster arrays), r.combine
and r.weight (think of this as how to combine spatial submodels into
one type of model), and others.
<p>Incidentally, do you prefer German? Try
<a href="http://www.laum.uni-hannover.de/iln/grass/handbuch">The University of Hannover's site:http://www.laum.uni-hannover.de/iln/grass/handbuch</a>
<hr>
<center><h3>Appendix A: Acquisition/Installation of GRASS4.13 Binaries</h3></center>
<p>This appendix describes how to acquire and install Linux binaries for
GRASS4.13 (the 3rd update to the last full release of GRASS, version
4.1).
<p>How to get these files:
<pre>
ftp moon.cecer.army.mil
login: anonymous
password: your email address
cd pub/grass/grass4.1/release/binaries/linux
image
mget grassa*
bye
Installation instructions:
********************************************************************
* GRASS 4.1 Update 3 for Linux
*
* This package contains GRASS programs only, *NO* GIS
* data is included. You can find example GRASS data at
* moon.cecer.army.mil
*
* Compiled by: Andy Burnett - burnett@zorro.cecer.army.mil
* compiled on: April 7, 1994
********************************************************************
System Requiremnts:
35 MB disk space to hold the binary distribution
System library requirements:
libc4.5.21 or greater
libX.so.3.1.0 or greater
If you are running libraries that are older than these, this binary
distribution will *NOT* run on your linux system.
--------------------------------------------------------------------------
Files in this release:
README_4.1.3 what you are currently reading
ginstall simple grass installation script
grassaa --------|
grassab |
grassac |
grassad |
grassae |-- the linux GRASS binaries
grassaf |
grassag |
grassah |
grassai |
grassaj |
grassak --------|
INSTALLATION:
To install this binary distribution of grass for linux, you
can simply run the ginstall script or you can unpack the files by
hand. I recommend using the ginstall script ... it's very simple and
should be bullet proof. To run the ginstall script, you will need
gawk (gnu awk) installed on your system and it needs to be in your
PATH.
If, however, you want to do things by hand, here's what you need to
do:
o make the destination directory (/usr/grass, /usr/local/grass,
whatever) This will become your GISBASE for grass.
********************* LOOK HERE **************************************
from here on, replace $GISBASE with the name of the directory you just
created
********************* LOOK HERE **************************************
o cat grassa? | gzip -d | (cd $GISBASE; tar xvf -)
This will unpack all the grass binaries into the $GISBASE directory
o copy $GISBASE/etc/moncap.sample to $GISBASE/etc/monitorcap and edit
it.
o change all occurrences of GBASE in that file to $GISBASE
o copy $GISBASE/etc/grass4.1 into a public directory (I suggest
/usr/bin)
o edit the copy you just made:
change all occurrences of GBASE to $GISBASE
</pre>
<hr>
<center><h3>Appendix B: Acquisition/Installation of GRASS4.1.5 Binaries</h3></center>
<p>This appendix describes how to acquire and install Linux binaries for
GRASS4.15 (the 5th and last update to the last full release of GRASS,
version 4.1).
<p>How to get these files:
<pre>
ftp moon.cecer.army.mil
login: anonymous
password: your email address
cd pub/grass/grass4.1/release/binaries/linux
image
mget linuxa*
bye
Installation instructions:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Files in this release:
README_4.1.5 what you are currently reading
install.sh simple grass installation script
linuxaa --------|
linuxab |
linuxac |
linuxad |
linuxae |-- the linux GRASS binaries, version 4.1.5
linuxaf |
linuxag |
linuxah |
linuxai --------|
* * * * * * * * * * *** * * * * * * * * * * * * * * * * * * * * * * *
*
The GRASS4.15 for Linux was compiled in my Linux box with the
following configuration:
Slackware 3.0
kernel 1.2.13
gcc 2.7.0
libc 5.0.9
flex 3.5.2
~ ~ ~ ~ ~ ~ ~
~ IMPORTANT: ~
~ ~ ~ ~ ~ ~ ~
THE LINUX GRASS 4.15 BINARIES ONLY WORK ON ELF-LINUX. THE BINARIES MAY
NOT WORK WITH EARLY VERSION OF KERNEL AND/OR GCC AND FLEX.
The binaries was tared and gziped, then split into 9 (close to 1.3 MB
- 1200 x 1K block) files named from linuxg.aa to linuxg.ai.
You should ftp all the linuxg.a* in binary mode and also get this
readme file and an installation script - install.sh. Please put all
of these files in the same directory - source directory.
At the source directory under the UNIX prompt, type
sh ./install.sh full_path_to_the_destination_directory
and it should automatically unzip and untar the linuxg.a* files to the
destination directory and also edit several site-specific files. The
total space your need is about 26 MB.
At the destination directory, your can find the grass4.1 script. It
should have been modified to reflect your installation directory.
Now, either move/copy the grass4.1 file to one of your PATH or use the
link command as below:
cd /usr/local/bin
ln -s destination_directory/etc/grass4.1 grass4.1
Now, your are ready to start GRASS by typing grass4.1 and you should
know how to run GRASS afterward.
There is a readme directory in the destination_directory/etc
directory. This directory has several readme files that come with
some incoming commands. You can find all the compiled commands of
this binaries in the commands.readme file. I can't guarantee that all
of them work but I have tested lots of them. If you find some
commands that don't work, please post a message on the grass user
group and we can solve it all together.
Yung-Tsung Kang,
Michigan State University
</pre>
<hr>
<center><h3>Appendix C: Acquisition/Compilation of GRASS Source Code</h3></center>
<p>The GRASS binaries for Linux tend to work. Why would anyone want to mess with
the source code?
<p>Let's try to answer this with another question: "Why can't I get the
source code to my GIS, so I can see how it works, and maybe fix some
things to work the way I like them?" (You probably know the answers
to this question, at least for many commercial software packages.)
<p>If you want to
<ol>
<li>Add any of the numerous existing alpha and contributed GRASS functions,
<li>Understand how a function works (did any programming shortcuts or
performance enhancements affect the accuracy of a function? Can
I improve the performance of a function?)
<li>Revise or enhance the code (if you do this, please see Appendix D!),
<li>Try compiling several tens of megabytes of source code,
this appendix is for you. Also check Appendix E.
</ol>
<p>First, you need to acquire the source code, and the GRASS Installation
Guide. You may also want to get the GRASS Programmer's Manual and
User's Reference Manual. To do this:
<pre>
ftp moon.cecer.army.mil
login: anonymous
password: your email address
cd pub/grass/grass4.1/release/source
get README.4
get README.5
image
mget s4* (or s5*, your choice)
cd ../../documents
get installGuide.ps.Z
cd /manuals/programmer/postscript
get progman.ps.Z
cd ../../user/postscript
get refman.ps.Z
bye
</pre>
<p>Don't forget this site. There are several tutorials on some of GRASS'
more advanced programs in the pub/grass/grass4.1/document directory.
There are two options for source code (I'm only discussing GRASS
version 4.14 here, though version 4.15 is also available) The
pub/grass/outgoing directory contains many contributed functions (and
many other candidates for enhancing your system).
<p>Follow the README.4 file for installing GRASS version 4.14 (which is
sometimes called version 4.1.4) source code. Follow the README.5 file
for installing GRASS version 4.15 (which is sometimes called version
4.1.5) source code.
<p>After installing the source code, uncompress and print
installGuide.ps.Z (or the troff version, if you prefer that and got it
from a neighboring directory). You might also want to uncompress and
print refman.ps.Z and progman.ps.Z at the same time. Note that
progman.ps.Z is called the programmer's manual, but also contains
valuable information about data formats and directory structures.
Advanced users may also want to know the GRASS system utilities, even
if they won't be calling them in code.
<p>Now, use the GRASS Installation Guide (from installGuide.ps.Z) to
guide yourself through the installation. The thickness of this
document may at first be intimidating. However, if you installed
Linux yourself, you should be ready to tackle a GRASS installation.
Don't be surprised if a function or two does not compile on your
system. I have a couple of uncompiled functions on my own Linux
system. Fortunately, these are functions that I don't use... Some
day I'll get back to them, fix them, and compile them!?
<hr>
<p>Here is a late-breaking addition, on how to install the newly released
<a href="http://www.baylor.edu/~grass">GRASS 4.2 from Baylor University:http://www.baylor.edu/~grass</a> This text
is as provided by Baylor, unedited by myself due to its release only a few
days ago. Please note the similarity with other installations..
<CENTER>
<h4>GRASS 4.2 Quick Start <br>Installtion Instuctions</h4>
</CENTER>
<i>WARNING:</i> These instructions pertain to the 4.2 release of GRASS
Users are urged to consult the complete installation guide for
more detailed instructions.
<p>
<b>$GIS/src</b> -
This directory contains scripts and files used to compile GRASS.
By running scripts and changing lists of programs you generate
GRASS binaries for your system.
<p>
You may mount a disk containing GRASS source on different types
of machines and compile without making source code copies. You
follow the following instructions for each machine.
<p>
<i>WARNING:</i> These instructions presume that you have familiarity with
UNIX, C, make, and shell scripting. Murphy's law visits GRASS
regularly and your expertise in these matters will be the best
defense against Mr. Murphy.
<p>
<i>WARNING:</i> These instructions and scripts have been used to compile
GRASS on various machines. Please mail results of using this
information for compiling GRASS on your platforms and operating
system to:
<p>
<center>grass@baylor.edu</center>
<p>
<b>DIRECTORY CONTENTS</b>
<p>
<pre>
GISGEN script which will compile GRASS
MAKELINKS script used after GISGEN to establish the user executable
commands
VERSION current version number and date of the GRASS release
generic/ system independent files need by gmake
gmake shell script which does compilations
make.def make variables
make.tail some additional make rules
head/ gmake header file(s) for this site. Header files are
created by running the utils/setup command.
lists/ lists of programs to be compiled
GRASS standard GRASS programs
local site specific GRASS programs
... architecture dependent GRASS programs
next_step/ files used by GISGEN to keep track of how far along
it is in the compilation. Used to restart
GISGEN (after a failure) where it left off.
utils/ contains the 'setup' script and all support scripts
and files needed by 'setup'
</pre>
<p>
<b>COMPILATION STEPS OVERVIEW</b>
<p>
<pre>
(1) Generate files that contain location and machine specific make
information.
(2) Edit files containing lists of location and machine specific
programs to be compiled (generally printer, digitizer, and graphics
drivers).
(3) Run GRASS compilation script
(4) Run GRASS program linking script
(5) Edit device driver configuratin files
(6) Compile GRASS contributed, alpha programs.
(7) Compile GRASS related and hybrid programs.
</pre>
<p>
<b>
COMPILATION STEPS (DETAILS)
</b>
<p>
<i>(1) Generate make support files</i><p>
Each machine and location needs to have GRASS compiled in ways that specify
different:
<ul>
<li>compilation and load flags
<li>system libraries
<li>installation directories
<li>default data bases and locations
</ul>
The shell script utils/setup assists you in define many of the make
options and definitions that will become part of every compile-time
generated makefile (about 350). It also creates your shell script for
compiling individual GRASS programs - gmake4.2.
<p>
Run "utils/setup" and answer the questions.
<p>
The makefile portions are placed in the head/ under a name which you
specify/approve in the utils/setup process. The executable shell script
which directs compilation is placed in (by default) /usr/local/bin.
<p>
Examine the just created file in head/ to make sure things are ok.
A brief description for each defined variable follows:
<p>
<pre>
ARCH = Key name identifying the architecture of the machine
on which you are compiling GRASS.
GISBASE = Directory into which compiled GRASS will be contained
UNIX_BIN = Local directory where the GRASS entry program and gmake
will be contained
DEFAULT_DATABASE= Directory where local GRASS data bases are contained
DEFAULT_LOCATION= GRASS data base that users get as the first default
COMPILE_FLAGS = Compilation flags
LDFLAGS = Load flags
TERMLIB = System library containing low-level cursor movement
CURSES = System library that supports screen cursor control
MATHLIB = System math library
LIBRULE = Method for archiving and randomizing libraries
USE_TERMIO = Flag to use the termio library if available
USE_MTIO = Flag to use the mtio library if available
CAN_CLEAR = Flag indicating that the terminal screen can be cleared
DIGITFLAGS = Flags to set owner and priority of the v.digit program
</pre>
<p>
<i>(2) Edit files containing lists of location and machine specified programs</i>
<p>
The directory lists/ contains files that list directories that will
be compiled. Directory names are relative to the GRASS src
directory. The file lists/GRASS lists all basic GRASS programs that
get compiled at every site. The file lists/local and lists/$ARCH.
<pre>
-----------------------------------------------------------------
$ARCH is the architecture name you approved while running the
utils/setup script. You can determine this by running:
gmake4.2 -sh | grep ARCH
-----------------------------------------------------------------
</pre>
There man not be a lists/$ARCH file, but you are free to create it to
add names of programs you want compiled specifically for this
architecture. It is an architecture-specific list which allows NFS
linked source code to compile one set of programs for one machine,
and another set for another machine. All machines that share the
same source code via NFS mounts will compile the directories listed
in lists/local.
<p>
All lists may contain comment lines - indicated by a # as the first
character in the line. The lists/local file contains lists of all
digitizer, graphics, and paint (hard-copy map) drivers. All machine
specific devices are commented out - you must uncomment those that
are particular to your site or architecture. You are encouraged to
move the graphics driver items to the appropriate lists/$ARCH file.
<p>
<i>(3) Run GRASS compilation program</i>
<p>
The script GISGEN drives the compilation process. If all goes well
you will be able to simply enter the command GISGEN and wait. The
entire compilation process takes from about 1/2 hour on the faster
workstations to about 8 hours on the slower workstations.
<p>
GISGEN collects all of the directory names to be compiled from lists/GRASS
lists/$ARCH and lists/local and begins running gmake4.2 in each directory.
Screen output is a collection of messages from GISGEN and from the UNIX
make program. Failure at any step will halt compilation. On failure
you might do one of the following things:
<p>
<pre>
1 - Fix a compilation problem by modifying code in the directory that
failed. After modification, return to this directory and rerun
GISGEN. Compilation will pick up at the failed directory and continue
down the list of directories if successful.
2 - Restart GISGEN. If the failure requires modifications to code already
compiled, or the compilation options you set in step 1, you must
remove next_step/$ARCH (or next_step/next_step if ar architecture name
was not specified in step 2. You may then rerun GISGEN.
3 - Skip the failed directory. In this case you must seek through the
files list/GRASS lists/$ARCH and lists/local to determine the directory
name that follows the failed directory name. The failed name is in
next_step/$ARCH and must be replaced in that file with the next name.
After editing, rerun GISGEN
</pre>
<p>
When complete GISGEN will put the word DONE into the next_step file and will
print the phrase "DONE generating GIS binary code" to the screen.
<p>
<i>(4) Run GRASS program linking script</i>
<p>
The GISGEN directs a compilation process that stashes the GRASS programs
away in directories unavailable to the user community. Most user commands
are actually links to a single program called "front.end". Links to this
program must be made for every actual GRASS program. This is done AFTER
GISGEN is finished. To make (or re-make) links for all user programs
run the script MAKELINKS.
<p>
<i>(5) Edit device driver configuratin files</i>
<p>
Your compiled system may any combination of several graphics, paint, and
digitizer drivers. Refer to the GRASS installation instructions for
details.
<p>
NOTE: If you have trouble compiling your graphics driver, go to the directory
$GIS/src/display/devices and compile the proper drivers manually using gmake4.2.
<p>
<i>(6) Compile GRASS contributed, alpha programs.</i>
<p>
GRASS programs come in three flavors:
<p>
MAIN - The programs are those compiled in step 3. They have stood the
test of time and are generally reliable programs.
<p>
ALPHA - Alpha programs are intended to be included with the MAIN programs
in the next release.
<p>
CONTRIB - Sites generate lots of special purpose programs in GRASS to get
some job done, but do not polish the effort sufficiently to
even be considered alpha code can be distributed in this category.
<p>
ALPHA programs are found in the directory src.alpha. You, the installer
may visit these programs and compile any that you desire. In directories
that contain Gmakefile files, simply run: gmake4.2
<p>
CONTRIB programs are in the directory src.contrib. The state of these
programs are varied. Some programs may compile with gmake4.2; others
are suitable as a starting point for programmers who will be writing
new software.
<p>
<i>(7) Compile GRASS related and hybrid programs.</i>
<p>
The GRASS user community has discovered that there are several public-domain
programs that are very useful in conjunction with GRASS. These are found
in the directory src.related. Compile these programs based on instructions
(or lack of instructions) in the individual directories.
<p>
Hybrid programs are those that mix the capabilities of GRASS with the
capabilities of one or more of the "related" programs. These are found
in the src.garden directory. They require successful compilation of
the "related" programs and generally compile using the gmake4.2 and
the included Gmakefile files.
<hr>
<p>The rest of the compilation should just take some time. If you have
already installed GRASS binaries, you should back up your system (or
at least get the working binaries out of the way of your
compilation!).
<p>Good Luck! And be secure in the likelihood that you can use the
compiled binaries if you bail out of a full compilation of the source
code.
<hr>
<center><h3>Appendix D: If you plan to enhance any part of GRASS, read this first!</h3></center>
<p>GRASS has been developed for over a decade as completely unrestricted
public domain source code and executables. Though there was initial
resistance to the existence of such robust software in the public
domain, many competitors learned to take advantage of GRASS. It has
reputedly been the intellectual stimulus for several enhancements to
other GISs. Several companies conducted business by installing and
customizing public domain GRASS for customers, and by providing other
value-added services such as data base development.
<p>As USA/CERL no longer supports the public version of GRASS, users are
free to use what currently exists. They're also currently completely
on their own. At least where the public domain version is concerned.
<p>There is a <a href="http://www.las.com/grassland">commercial version of GRASS:http://www.las.com/grassland</a>, adapted from the public domain
version by Logiciels et Applications Scientifiques (L.A.S) Inc. of
Montreal . In a recent check, LAS
sold its GRASSLAND for Sun, Linux and Windows NT. LAS is trying to
encourage the continuation of a robust public domain Linux, partly as
a source of new ideas and code for their own developments.
<center><h3>Appendix E: Example Linux versions of some critical GRASS files.</h3></center>
<p>This appendix is the home of Linux-specific examples of selected GRASS
configuration files. Currently, only several examples of a single file
are offered. However, this is the most important file for
configuration! Later, examples of database configuration files (e.g.
DEFAULT_WIND) and other files may appear.
<p>In the Installation Guide (pp. 10-11) you will see mention of the
[header] file in directory $GIS/src/CMD/header (where $GIS is the
directory in which you place GRASS - some folks put this in /usr/local -
I put everything in a GRASS' own filesystem/directory /user/grass4.1).
The installation guide favors Sun systems, as these were the development
environment for GRASS4. (In case you cared, Masscomp workstations were
earlier development environments.) Below are examples of this <header>
file for linux (which you might want to name linux in your
$GIS/src/CMD/header directory. You may want to refer to this section
when running the setup ($GIS/src/CMD/utils/setup) command.
<hr>
<p>One version:
<pre>
CC = gcc
ARCH =
GISBASE = /user/grass4.1
UNIX_BIN = /user/grass4.1/bin
DEFAULT_DATABASE = /user/grass4.1/data
DEFAULT_LOCATION = china
COMPILE_FLAGS = -O2
LDFLAGS = -s
XCFLAGS = -D_NO_PROTO -DXM_1_1_BC
XLDFLAGS =
XINCPATH =
XMINCPATH =
XLIBPATH =
XTLIBPATH = -L/usr/lib
XMLIBPATH = -L/usr/lib
XLIB = -lX11
XTLIB = -lXt
XMLIB = -lXm
XEXTRALIBS =
TERMLIB =
CURSES = -lcurses $(TERMLIB)
MATHLIB = -lm
# LIBRULE = ar ruv $@ $?
# LIBRULE = ar ruv $@ $?; ranlib $@
# LIBRULE = ar ruv $@ $?; ar ts $@
# LIBRULE = ar rc $@ `lorder $(OBJ) | tsort`
LIBRULE = ar ruv $@ $?
USE_TERMIO = -DUSE_TERMIO
USE_MTIO = -DUSE_MTIO
USE_FTIME = -DUSE_FTIME
DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY
VECTLIBFLAGS =
GETHOSTNAME = -DGETHOSTNAME_OK
</pre>
<hr>Another version:
<pre>
#CC = gcc
#CC = gcc -ggdb -traditional
CC = gcc -traditional
#CC = gcc -static
ARCH = linux
GISBASE = /usr2/local/grass/grass4.1
UNIX_BIN = /usr/local/bin
DEFAULT_DATABASE = /usr2/local/grass
DEFAULT_LOCATION = grass4.1
COMPILE_FLAGS =
#COMPILE_FLAGS = -O
LDFLAGS = -s
XCFLAGS = -D_NO_PROTO
XLDFLAGS =
XINCPATH = -I$GISBASE/xgrass
#XINCPATH =
XMINCPATH =
XLIBPATH = -L/usr/lib
XTLIBPATH = -L/usr/lib
XMLIBPATH = -L/usr/lib
XLIB = -lX11
XTLIB = -lXt
XMLIB = -lXm
XEXTRALIBS =
TERMLIB =
CURSES = -lcurses $(TERMLIB)
MATHLIB = -lm
# LIBRULE = ar ruv $@ $?
# LIBRULE = ar ruv $@ $?; ranlib $@
# LIBRULE = ar ruv $@ $?; ar ts $@
# LIBRULE = ar rc $@ `lorder $(OBJ) | tsort`
LIBRULE = ar ruv $@ $?; ranlib $@
USE_TERMIO = -DUSE_TERMIO
USE_MTIO = -DUSE_MTIO
USE_FTIME = -DUSE_FTIME
DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY
VECTLIBFLAGS =
GETHOSTNAME = -DGETHOSTNAME_OK
</pre>
<hr>
<p>Another version:
<pre>
#CC = gcc -traditional -ggdb
CC = gcc -traditional -m486
#CC = gcc
ARCH = linux
GISBASE = /usr/local/grass/grass4.1
UNIX_BIN = /usr/local/bin
DEFAULT_DATABASE = /usr/local/grass
DEFAULT_LOCATION = grass4.1
COMPILE_FLAGS = -O2
LDFLAGS = -s
XCFLAGS = -D_NO_PROTO -DXM_1_1_BC
XLDFLAGS =
XINCPATH =
XMINCPATH =
XLIBPATH = -L/usr/lib
XTLIBPATH = -L/usr/lib
XMLIBPATH = -L/usr/lib
XLIB = -lX11
XTLIB = -lXt
XMLIB = -lXm
XEXTRALIBS = -lXmu
TERMLIB =
CURSES = -lcurses $(TERMLIB)
MATHLIB = -lm
# LIBRULE = ar ruv $@ $?
# LIBRULE = ar ruv $@ $?; ranlib $@
# LIBRULE = ar ruv $@ $?; ar ts $@
# LIBRULE = ar rc $@ `lorder $(OBJ) | tsort`
LIBRULE = ar ruv $@ $?; ranlib $@
#USE_TERMIO = #-DUSE_TERMIO
USE_TERMIO = -DUSE_TERMIO
USE_MTIO = -DUSE_MTIO
USE_FTIME = -DUSE_FTIME
DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY
VECTLIBFLAGS =
GETHOSTNAME = -DGETHOSTNAME_OK
</pre>
<hr>
<p>Yet another version:
<pre>
CC = cc
ARCH = linux
GISBASE = /usr/local/grass4.15/linux
UNIX_BIN = /usr/local/grass4.15/linux
DEFAULT_DATABASE = /data/grassdata
DEFAULT_LOCATION =
# -fwritable-strings - for ps.map only
#COMPILE_FLAGS = -O -m486 -fwritable-strings
COMPILE_FLAGS = -O -m486
LDFLAGS = -s
XCFLAGS = -D_NO_PROTO
XLDFLAGS =
XINCPATH =
XMINCPATH =
XLIBPATH = -L/usr/X11R6/lib
XTLIBPATH = -L/usr/lib
XMLIBPATH = -L/usr/lib
XLIB = -lX11
XTLIB = -lXt
XMLIB = -lXm
XEXTRALIBS =
TERMLIB =
CURSES = -lcurses $(TERMLIB)
MATHLIB = -lm
# LIBRULE = ar ruv $@ $?
# LIBRULE = ar ruv $@ $?; ranlib $@
# LIBRULE = ar ruv $@ $?; ar ts $@
# LIBRULE = ar rc $@ `lorder $(OBJ) | tsort`
LIBRULE = ar ruv $@ $?
USE_TERMIO = -DUSE_TERMIO
USE_MTIO = -DUSE_MTIO
USE_FTIME = -DUSE_FTIME
DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY
VECTLIBFLAGS = -DPORTABLE_3
GETHOSTNAME = -DGETHOSTNAME_OK
</pre>
<p>Intimidating? It probably shouldn't be if you've configured X Windows
on your Linux box. These examples should give you patterns to look
for when running the setup utility in GRASS (described in the
Installation Guide).
</body>
</html>
