# import raster map into new location:

r.in.gdal -oe in=$MAP out=$MAP location=$LOCATION

If [ $? -eq 1 ] ; then

echo An error occured. Stop. exit 1

restore saved $H0ME/.grassrc5

if test -f /tmp/$TEMPDIR.grassrc5 ; then

mv /tmp/$TEMPDIR.grassrc5 $H0ME/.grassrc5

echo Now launch GRASS with:

echo grass53 $GISDBASE/$LOCATION/PERMANENT

In case that no projection information is found in the raster data set, you may use g.setproj to later store the projection information. Note that g.setproj does not reproject any data. The above script accepts only raster data sets. Because a general import tool for vector data does not yet exist in GRASS 5.3 (but in GRASS 5.7), the script for the same task based on vector data would require vector import modules and a format detector based on file extensions. Another approach would be to query the data format as additional third parameter. In this way the script can be extended into a general LOCATION creation and import script.

Another method to launch GRASS directly without manually specifying the names of LOCATION, MAPSET and DATABASE is:

grass53 /usr/local/share/grassdata/spearfish/user1

This is only successful if the LOCATION and MAPSET exist.

11.4. NOTES ON PROGRAMMING GRASS MODULES IN C

This section explains the GRASS code organization for a user with basic C language programming knowledge. While we cannot explain GRASS programming within this book, we provide a brief introduction to the huge code base. GRASS provides an ANSI C language API with several hundred GIS functions, from reading and writing maps to area and distance calculations for georeferenced data as well as attribute handling and map visualization. All important aspects of GRASS programming are covered in the GRASS 5.3 Programmers Manual (available from the GRASS Web site). To understand the usage of the GRASS API it is helpful to explore the existing modules. The

general structure of modules is similar, with each module stored in a directory of the GRASS source code. You can find further useful tips for GRASS programming style as well as recommendations to avoid portability traps in the file SUBMITTING. This file is included in the source code.

It is important to know that the GRASS modules are linked against an internal front.end . The front.end module will call the interactive version of the command if there are no command-line arguments entered by the user. Otherwise, it will run the command-line version. If only one version of the specific command exists (for example, if there is only a command-line version available) the existing command is executed. Code parameters and flags are defined within each module. They are used to ask user to define map names and other options.

GRASS source code structure. The GRASS 5.3 source code structure is as follows:

GRASS GIS library (only the most relevant components are listed):

- src/CMD/

- src/include/

- src/libes/

- src/display/devices

- src/fonts/

- src/front.end/

# internal scripts for compilation

# header files

# GIS library routines

# display and file drivers

# character fonts

# internal routines for the

interactive mode of modules

Modules (standard tree):

- src/display/

- src/general/

- src/imagery/

- src/mapdev/

- src/misc/

- src/paint/

- src/ps.map/

- src/raster/

- src/scripts/

- src/sites/

- src/tcltkgrass/

- html/

modules for displaying maps in the

GRASS monitor file management modules image processing modules vector modules miscellaneous modules paint driver (PPM) postscript driver raster modules scripts sites modules Tcl/Tk GUI

modules descriptions

Contributions form various institutions (additional contributions are in the standard tree):

- src.contrib/

Modules with linked simulation models and various interfaces:

- src.garden/

PGM=i.sat.reflectance HOME=$(BIN CMD)

1JBES= $(IMAGERYLIB) $(GISLIB) $(VASKL1B) $(VASK) DEPL1BS=$(DEPIMAGERYLIB) $(DEPG1SLIB) OBJ = main.o\

open.o\

atmos.o\

sun pos.o\

correction.o\

histogram.o\

history.о

Note that this structure is subject to change in future releases.

The GRASS programming library (C API) is structured as follows (typical function name prefixes for related library functions are listed in squared brackets):

GIS library: database routines (GRASS file management), memory management, parser (parameter identification on command line), projections, raster data management etc. [G ]

vector library: management of area, line, and point vector data [Vect , V2 , dig ]

image data library: image processing file management

site data library: site data management [G sites ]

display library: graphical output to the monitor [D ]

raster graphics library: display raster graphics on devices [R ]

segment library: segmented data management [ segment ]

vask library: control of cursor keys etc. [V ]

rowio library: for parallel row analysis of raster data [rowio ]

Modules consist of one or more C program files (*.c), the local header files (*.h) and a Gmakefile. GRASS 5.3 is provided with its own make routine: gmake53. The file Gmakefile contains instructions about files to be compiled and libraries to be used (GRASS and UNIX libraries). The GRASS libraries are predefined as variables. The structure of Gmakefile follows special rules. A simple example illustrates a typical Gmakefile (it is important to generate indents with <TAB>, not with blanks!):