mirror of https://github.com/tLDP/LDP
2053 lines
77 KiB
Plaintext
2053 lines
77 KiB
Plaintext
<!doctype article public "-//OASIS//DTD DocBook V3.1//EN">
|
|
<article id="GIS-GRASS-HOWTO"><?dbhtml filename="GIS-GRASS-HOWTO.html">
|
|
|
|
<artheader>
|
|
<title>The Geographic Information Systems: GRASS HOWTO</title>
|
|
|
|
<author>
|
|
<firstname>David</firstname>
|
|
<othername>A.</othername>
|
|
<surname>Hastings</surname>
|
|
<affiliation>
|
|
<orgname>U. S. Department of Commerce</orgname>
|
|
<orgdiv>National Oceanic and Atmospheric Administration</orgdiv>
|
|
<orgdiv>National Geophysical Data Center</orgdiv>
|
|
<address>
|
|
<city>Boulder</city>, <state>CO</state> <postcode>80303</postcode>
|
|
<country>USA</country>
|
|
<email>dah@ngdc.noaa.gov</email>
|
|
</address>
|
|
</affiliation>
|
|
</author>
|
|
|
|
<othercredit>
|
|
<firstname>David</firstname>
|
|
<othername>C.</othername>
|
|
<surname>Merrill</surname>
|
|
<honorific>Ph.D.</honorific>
|
|
<contrib>Conversion to DocBook SGML</contrib>
|
|
</othercredit>
|
|
|
|
<keywordset>
|
|
<keyword>GIS</keyword>
|
|
<keyword>GRASS</keyword>
|
|
</keywordset>
|
|
|
|
<abstract>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
apps'"?) For more on this topic, see Section 8 below.
|
|
</para>
|
|
</abstract>
|
|
|
|
<legalnotice>
|
|
<para>
|
|
This document is not subject to copyright. See section 9 below.
|
|
</para>
|
|
</legalnotice>
|
|
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>1.0</revnumber>
|
|
<date>13 November 1997</date>
|
|
<authorinitials>dah</authorinitials>
|
|
<revremark>Initial Release</revremark>
|
|
</revision>
|
|
|
|
</revhistory>
|
|
</artheader>
|
|
|
|
|
|
<sect1 label="1" ID="whatisgis">
|
|
<title>What is a GIS?</title>
|
|
|
|
<para>
|
|
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):
|
|
</para>
|
|
|
|
<orderedlist numeration="Arabic">
|
|
<listitem>
|
|
<para>
|
|
(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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
(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
|
|
<emphasis>spatial</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
(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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Another definition can be found at
|
|
<ulink url="http://www.geo.ed.ac.uk/home/research/whatisgis.html"><citetitle>the University of Edinburgh.</citetitle></ulink>
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="2" id="whatisgrass">
|
|
<title>What Is GRASS?</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Copied from Project Assist
|
|
<ulink url="http://www.geog.le.ac.uk/assist/grass"><citetitle>Intro to GRASS</citetitle></ulink>.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="3" id="history">
|
|
<title>A Brief History of GRASS</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
GRASS developed a programming style characterized by:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The ability to handle both major GIS data types: raster and vector.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The favoring of raster data processing, as scientific analysis was
|
|
easier to encode with raster (than for vector) data models.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The ability to run-length encode raster data files, in order to
|
|
greatly reduce file sizes of most files.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<ulink url="http://www.las.com/grassland/"><citetitle>GRASSLANDS</citetitle></ulink>,
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="3.1" id="managementmodel">
|
|
<title>A Re-Invogorated GRASS Management Model</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="3.2" id="futuremanagement">
|
|
<title>Continued Assessment of Future GRASS Management</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="4" id="requirements">
|
|
<title>System Requirements for GRASS</title>
|
|
|
|
<para>
|
|
Minimum requirements include:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
8 Mbytes of memory (of course, more is better..)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
100 Mbytes of free disk space
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
~40 mb for executables,
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
~40 mb for source code
|
|
(which you can ignore if you merely install the Linux binaries)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
~? for data
|
|
(the veritable bottomless pit can be filled with data,
|
|
if you so choose)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
GRASS runs on Linux kernel versions as old as 1.2.13 (see more
|
|
information in the appendices for various specific binaries).
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
If you find any other hardware/OS requirements that should be mentioned,
|
|
please let me know!
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="5" id="acquire">
|
|
<title>How to Acquire GRASS</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The main way to acquire GRASS is to get it via anonymous ftp from:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>The new site at
|
|
<ulink url="http://www.baylor.edu/~grass"><citetitle>Baylor University</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<ulink url="http://www.cecer.army.mil/grass"><citetitle>The traditional site</citetitle></ulink>
|
|
at
|
|
<ulink url="http://www.cecer.army.mil"><citetitle>USA/CERL</citetitle></ulink>
|
|
or from mirrors cited at USA/CERL's website:
|
|
</para>
|
|
|
|
<para>
|
|
The ftp location is:
|
|
</para>
|
|
|
|
<para>
|
|
moon.cecer.army.mil
|
|
</para>
|
|
|
|
<para>
|
|
Appendix A describes how to acquire and install GRASS4.13 compiled
|
|
binaries from USA/CERL. (See section 6 before installing GRASS!)
|
|
</para>
|
|
|
|
<para>
|
|
Appendix B describes how to acquire and install GRASS4.15 compiled
|
|
binaries from USA/CERL. (See section 6 before installing GRASS!)
|
|
</para>
|
|
|
|
<para>
|
|
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!)
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="6" id="installation">
|
|
<title>How to Get GRASS Running on Your Linux-based Computer.</title>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The GRASS data directories. These can go anywhere, as they are
|
|
specified in configuration files.
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
/user/grass4.1/bin (I usually put grass4.1 and gmake4.1 here...)
|
|
/data
|
|
/dev
|
|
/etc
|
|
/man
|
|
/src
|
|
/src.alpha
|
|
/src.contrib
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
I'm currently building a GRASS5.0 site, which then goes under:
|
|
</para>
|
|
|
|
<programlisting>
|
|
/user/grass5/bin
|
|
/data (some GRASS5 data formats have changed...)
|
|
/dev
|
|
/etc
|
|
</programlisting>
|
|
|
|
<para>
|
|
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"!
|
|
</para>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
I personally recommend that you start with the Spearfish and Global
|
|
databases available from USA/CERL:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
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.)
|
|
</para>
|
|
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="7" id="websupport">
|
|
<title>Web-based Support for GRASS (and for GIS Matters in General)</title>
|
|
|
|
<para>
|
|
Support for a public domain program? No way, they say! Actually, as a
|
|
user of Linux, you probably know better.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
Valuable "books" available on the Internet are noted in the References
|
|
(Section 10).
|
|
</para>
|
|
|
|
<para>
|
|
World Wide Web-based training materials, including training in GRASS,
|
|
are highlighted in the
|
|
<ulink url="http://www.ngdc.noaa.gov/seg/tools/gis/referenc.html"><citetitle>CyberInstute Short Course in GIS</citetitle></ulink>
|
|
(then scan down for the link(s) to Web-based tutorials in GIS).
|
|
</para>
|
|
|
|
<para>
|
|
One of the better GRASS tutorials is
|
|
<ulink url="http://www.geog.le.ac.uk/assist/grass"><citetitle>Project Assist's - Intro to GRASS</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
Other good sites:
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://www.csu.edu"><citetitle>Central Washington University</citetitle></ulink>
|
|
was an
|
|
<ulink url="http://www.csu.edu/~gishome/grass.htm"><citetitle>early GRASS user and training facility</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://cast.uark.edu/local/hunt"><citetitle>Starting the hunt for mostly free spatial data</citetitle></ulink>
|
|
by Stephan Pollard
|
|
This is based at the Center for Advanced Spatial Technology of the
|
|
University of Arkansas, another early educator with GRASS.
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://www.purdue.edu"><citetitle>Purdue University</citetitle></ulink>
|
|
has several
|
|
<ulink url="http://pasture.ecn.purdue.edu/~aggrass"><citetitle>GRASS features</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://www.cecer.army.mil/grass/userman/main-alpha.html"><citetitle>USA/CERL's online GRASS manual</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://www.rutgers.edu"><citetitle>Rutgers University's</citetitle></ulink>
|
|
<ulink url="http://deathstar.rutgers.edu/grassinfo.html"><citetitle>GRASS Information Center</citetitle></ulink>
|
|
at the
|
|
<ulink url="http://deathstar.rutgers.edu"><citetitle>Center for Remote Sensing and Spacial Analysis</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
<ulink url="http://www.regis.berkeley.edu"><citetitle>The REGIS project</citetitle></ulink>
|
|
at
|
|
<ulink url="http://www.berkeley.edu"><citetitle>The University of California at Berkeley</citetitle></ulink>
|
|
has a Linux version of GRASS available via ftp, and also has
|
|
<ulink url="http://www.berkeley.edu/glinks"><citetitle>a Web-based version of GRASS called GRASSLINKS</citetitle></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
After getting trained by the books and Web-based tutorials noted just
|
|
above, where do you turn to for specific advice???
|
|
</para>
|
|
|
|
<para>
|
|
Probably the best source of support these days is usenet newsgroup
|
|
<ulink url="news:comp.infosystems.gis"><citetitle>comp.infosystems.gis</citetitle></ulink>
|
|
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
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
"how do I find data on this topic for this area?"
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
"how do I convert these data for use in my Aardvark GIS?"
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
"how do I get this function to work in my Aardvark GIS?"
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
"which GIS can I use to solve my particular problem?"
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
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
|
|
<ulink url="http://www.dejanews.com"><citetitle>DejaNews</citetitle></ulink>
|
|
to see what might appear from the usenet archives.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="8" id="future">
|
|
<title>The Future of GRASS?</title>
|
|
|
|
<para>
|
|
Excellent question! Several possible answers have been thrown out:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Others hope that GRASS' previous management model under USA/CERL
|
|
has left it ready for a new model. Perhaps:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Under a distributed management model... perhaps somewhat like Linux?
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Perhaps a bit of a hybrid? Perhaps a Web-based effort could
|
|
spawn a series of usenet discussion groups beginning with
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass, and evolving to:
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.academics
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.publicservice
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.commercialvalueadded
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.commercialdistributors
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.programming
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.users
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
comp.infosystems.gis.grass.centralcommittee
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
GRASS offers considerable potential for:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
<ulink url="www.regis.berkeley.edu/grasslinks"><citetitle>GRASSLINKS</citetitle></ulink>,
|
|
developed at
|
|
<ulink url="www.berkeley.edu"><citetitle>The University of California at Berkeley</citetitle></ulink>,
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>GIS research and development. For example - do you want to
|
|
experiment with a different data model? Add it to GRASS!
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Who would be the Linus Torvalds 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.
|
|
</para>
|
|
|
|
<para>
|
|
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....
|
|
</para>
|
|
|
|
<para>
|
|
Comments would be appreciated!
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 label="9" id="copyright">
|
|
<title>Copyright Notice, and Notice on Support of this Document</title>
|
|
|
|
<sect2>
|
|
<title>Copyright notice</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Notice on support of this document</title>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 label="10" id="references">
|
|
<title>References</title>
|
|
|
|
<para>
|
|
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
|
|
<ulink url="http://www.ngdc.noaa.gov/seg/tools/gis/referenc.html"><citetitle>CyberInstitute Short Course on Geographic Information Systems</citetitle></ulink>
|
|
(convened by myself):
|
|
</para>
|
|
|
|
<para>
|
|
Also check
|
|
<ulink url="http://www.baylor.edu"><citetitle>Baylor University</citetitle></ulink>'s growing
|
|
<ulink url="http://www.baylor.edu/~grass"><citetitle>GRASS Home Page</citetitle></ulink>
|
|
and
|
|
<ulink url="http://www.cecer.army.mil"><citetitle>USA/CERL</citetitle></ulink>'s
|
|
<ulink url="http://www.cecer.army.mil/grass"><citetitle>GRASS Home Page</citetitle></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
For a good collection of references on GRASS, try this procedure, to
|
|
load up on reference goodies from USA/CERL:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
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)
|
|
</programlisting>
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
installGuide => The GRASS Installation Guide (you need this to compile GRASS source code)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
grassman => The GRASS Beginner's Manual (intro to GRASS)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
refman => The GRASS User's Reference Manual (function guide)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
progman => The GRASS Programmer's Manual (and administrator's guide - this is valuable for info about data formats, etc.)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<appendix label="A" id="install413">
|
|
<title>Acquisition/Installation of GRASS4.13 Binaries</title>
|
|
|
|
<abstract>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</abstract>
|
|
|
|
<para>
|
|
How to get these files:
|
|
</para>
|
|
|
|
<programlisting>
|
|
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
|
|
|
|
</programlisting>
|
|
|
|
</appendix>
|
|
|
|
<appendix label="B" id="install415">
|
|
<title>Acquisition/Installation of GRASS4.1.5 Binaries</title>
|
|
|
|
<abstract>
|
|
<para>
|
|
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).
|
|
</para>
|
|
</abstract>
|
|
|
|
<para>
|
|
How to get these files:
|
|
</para>
|
|
|
|
<programlisting>
|
|
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, you 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
|
|
</programlisting>
|
|
</appendix>
|
|
|
|
<appendix label="C" id="compiling">
|
|
<title>Acquisition/Compilation of GRASS Source Code</title>
|
|
|
|
<para>
|
|
The GRASS binaries for Linux tend to work. Why would anyone want to mess with
|
|
the source code?
|
|
</para>
|
|
|
|
<para>
|
|
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.)
|
|
</para>
|
|
|
|
<para>
|
|
If you want to
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
Add any of the numerous existing alpha and contributed GRASS functions,
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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?)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Revise or enhance the code (if you do this, please see Appendix D!),
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Try compiling several tens of megabytes of source code,
|
|
this appendix is for you. Also check Appendix E.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<programlisting>
|
|
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
|
|
</programlisting>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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!?
|
|
</para>
|
|
|
|
<para>
|
|
Here is a late-breaking addition, on how to install the newly released
|
|
<ulink url="http://www.baylor.edu/~grass"><citetitle>GRASS 4.2</citetitle></ulink>
|
|
from
|
|
<ulink url="http://www.baylor.edu"><citetitle>Baylor University</citetitle></ulink>
|
|
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..
|
|
</para>
|
|
|
|
<sect1 id="quickstart42">
|
|
<title>GRASS 4.2 Quick Start</title>
|
|
<subtitle>Installation Instructions</subtitle>
|
|
|
|
<warning>
|
|
<para>
|
|
These instructions pertain to the 4.2 release of GRASS.
|
|
Users are urged to consult the complete installation guide for
|
|
more detailed instructions.
|
|
</para>
|
|
</warning>
|
|
|
|
<programlisting>
|
|
$GIS/src -
|
|
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.
|
|
|
|
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.
|
|
|
|
WARNING: 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.
|
|
|
|
WARNING: 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:
|
|
|
|
grass@baylor.edu
|
|
|
|
DIRECTORY CONTENTS
|
|
|
|
|
|
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'
|
|
|
|
|
|
COMPILATION STEPS OVERVIEW
|
|
|
|
(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.
|
|
|
|
COMPILATION STEPS (DETAILS)
|
|
|
|
(1) Generate make support files
|
|
|
|
Each machine and location needs to have GRASS compiled in ways that specify
|
|
different:
|
|
|
|
compilation and load flags
|
|
system libraries
|
|
installation directories
|
|
idefault data bases and locations
|
|
|
|
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.
|
|
|
|
Run "utils/setup" and answer the questions.
|
|
|
|
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.
|
|
|
|
Examine the just created file in head/ to make sure things are ok.
|
|
A brief description for each defined variable follows:
|
|
|
|
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
|
|
|
|
(2) Edit files containing lists of location and machine specified programs
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------
|
|
$ARCH is the architecture name you approved while running the
|
|
utils/setup script. You can determine this by running:
|
|
gmake4.2 -sh | grep ARCH
|
|
-----------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
(3) Run GRASS compilation program
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
(4) Run GRASS program linking script
|
|
|
|
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.
|
|
|
|
(5) Edit device driver configuratin files
|
|
|
|
Your compiled system may any combination of several graphics, paint, and
|
|
digitizer drivers. Refer to the GRASS installation instructions for
|
|
details.
|
|
|
|
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.
|
|
|
|
(6) Compile GRASS contributed, alpha programs.
|
|
|
|
GRASS programs come in three flavors:
|
|
|
|
MAIN - The programs are those compiled in step 3. They have stood the
|
|
test of time and are generally reliable programs.
|
|
|
|
ALPHA - Alpha programs are intended to be included with the MAIN programs
|
|
in the next release.
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
(7) Compile GRASS related and hybrid programs.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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!).
|
|
|
|
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.
|
|
|
|
</programlisting>
|
|
</sect1>
|
|
</appendix>
|
|
|
|
|
|
<appendix label="D" id="enhancing">
|
|
<title>Enhancing GRASS</title>
|
|
<subtitle>If you plant to enhance any part of GRASS, read this first!</subtitle>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There is a
|
|
<ulink url="http://www.las.com/grassland"><citetitle>commercial version of GRASS</citetitle></ulink>,
|
|
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.
|
|
</para>
|
|
|
|
</appendix>
|
|
|
|
<appendix label="E" id="samples">
|
|
<title>Sample Files</title>
|
|
<subtitle>Example Linux versions of some critical GRASS files</subtitle>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
One version:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
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
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
Another version:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
#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
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
Another version:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
#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
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
Yet another version:
|
|
</para>
|
|
|
|
<para>
|
|
<programlisting>
|
|
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
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
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).
|
|
</para>
|
|
</appendix>
|
|
|
|
</article>
|