Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Linux Tracker

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 83 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here




A Brief History of GRASS

3. A Brief History of 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 & 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.

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.




Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.12 Seconds