The Geographic Information Systems: GRASS HOWTO
Boulder, CO 80303 USA dah@ngdc.noaa.gov
Revision HistoryRevision 1.013 November 1997Revised by: dahInitial Release
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.
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.
----; Table of Contents; 1. What is a GIS?; 2. What Is GRASS?; 3. A Brief History of GRASS; 3.1. A Re-Invogorated GRASS Management Model; 3.2. Continued Assessment of Future GRASS Management; 4. System Requirements for GRASS; 5. How to Acquire GRASS; 6. How to Get GRASS Running on Your Linux-based Computer.; 7. Web-based Support for GRASS (and for GIS Matters in General); 8. The Future of GRASS?; 9. Copyright Notice, and Notice on Support of this Document: ; 9.1. Copyright notice; 9.2. Notice on support of this document; 10. References; A. Acquisition/Installation of GRASS4.13 Binaries; B. Acquisition/Installation of GRASS4.1.5 Binaries; C. Acquisition/Compilation of GRASS Source Code: ; C.1. GRASS 4.2 Quick Start; D. Enhancing GRASS; E. Sample Files
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):
#
(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.
# #
(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 spatial 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.
# #
(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
who have not yet seen what can be accomplished scientifically by a select few GISs that go beyond cartographic approaches.
# #
Another definition can be found at
the University of Edinburgh.
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.
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.
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.
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).
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.
Copied from Project Assist
Intro to GRASS.
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.
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.
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.
GRASS developed a programming style characterized by:
*
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.
* *
The ability to handle both major GIS data types: raster and vector.
* *
The favoring of raster data processing, as scientific analysis was
easier to encode with raster (than for vector) data models.
* *
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.
* *
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.
* *
The ability to run-length encode raster data files, in order to
greatly reduce file sizes of most files.
* *
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.
* *
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.
* *
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.
*
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.
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.
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 8 M University, The University of California at Berkeley, and Rutgers University.
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.
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).
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 GRASSLANDS, 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.
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 8 M University, for those desiring very inexpensive access to GRASS for Windows 95.
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.
Minimum requirements include:
*
8 Mbytes of memory (of course, more is better..)
* *
100 Mbytes of free disk space
* *
40 mb for executables,
* *
40 mb for source code
(which you can ignore if you merely install the Linux binaries)
* *
? for data
(the veritable bottomless pit can be filled with data, if you so choose)
*
GRASS runs on Linux kernel versions as old as 1.2.13 (see more
information in the appendices for various specific binaries).
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.
If you find any other hardware/OS requirements that should be mentioned,
please let me know!
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.
The main way to acquire GRASS is to get it via anonymous ftp from:
#
The new site at Baylor University
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.
# #
The traditional site
at USA/CERL
The ftp location is:
moon.cecer.army.mil
Appendix A describes how to acquire and install GRASS4.13 compiled
binaries from USA/CERL. (See section 6 before installing GRASS!)
Appendix B describes how to acquire and install GRASS4.15 compiled
binaries from USA/CERL. (See section 6 before installing GRASS!)
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!)
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.
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:
#
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).
# #
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).
# #
The GRASS data directories. These can go anywhere, as they are
specified in configuration files.
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:
/user/grass4.1/bin (I usually put grass4.1 and gmake4.1 here...) /data /dev /etc /man /src /src.alpha /src.contrib
I'm currently building a GRASS5.0 site, which then goes under:
/user/grass5/bin /data (some GRASS5 data formats have changed...) /dev /etc
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"!
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).
I personally recommend that you start with the Spearfish and Global
databases available from USA/CERL:
#
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.
# #
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.
#
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.)
Support for a public domain program? No way, they say! Actually, as a
user of Linux, you probably know better.
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.
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).
Valuable "books" available on the Internet are noted in the References
(Section 10).
World Wide Web-based training materials, including training in GRASS,
are highlighted in the !CyberInstute? Short Course in GIS (then scan down for the link(s) to Web-based tutorials in GIS).
One of the better GRASS tutorials is
Project Assist's - Intro to GRASS
Other good sites:
Central Washington University
was an early GRASS user and training facility
Starting the hunt for mostly free spatial data
by Stephan Pollard This is based at the Center for Advanced Spatial Technology of the University of Arkansas, another early educator with GRASS.
Purdue University
has several GRASS features
USA/CERL's online GRASS manual
Rutgers University's
GRASS Information Center at the Center for Remote Sensing and Spacial Analysis
The REGIS project
at The University of California at Berkeley has a Linux version of GRASS available via ftp, and also has a Web-based version of GRASS called GRASSLINKS.
After getting trained by the books and Web-based tutorials noted just
above, where do you turn to for specific advice???
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
*
"how do I find data on this topic for this area?"
* *
"how do I convert these data for use in my Aardvark GIS?"
* *
"how do I get this function to work in my Aardvark GIS?"
* *
"which GIS can I use to solve my particular problem?"
*
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
lib/CachedMarkup.php (In template 'browse' < 'body' < 'html'):257: Error: Pure virtual
lib/main.php:944: Notice: PageInfo: Cannot find action page
lib/main.php:839: Notice: PageInfo: Unknown action
lib/InlineParser.php:336: Warning: Invalid [] syntax ignored: [[8 your own subject of
lib/CachedMarkup.php (In template 'browse' < 'body' < 'html'):257: Error: Pure virtual