|
GRASS Programmer's Manual
7.0.svn(2012)-r51645
|
|
GRASS Programmer's Manual
7.0.svn(2012)-r51645
|
by GRASS Development Team (http://grass.osgeo.org)
This chapter is divided as follows:
The GIS Library is the primary programming library provided with the GRASS system. Programs must use this libary to access the GIS database. It contains the routines which locate, create, open, rename, and remove GRASS database files. It contains the routines which read and write raster files. It contains routines which interface the user to the database, including prompting the user, listing available files, validating user access, etc. It also has some general purpose routines (string manipulation, user information, etc.) which are not tied directly to database processing.
It is assumed that the reader has read File structure of GRASS Location for a general description of GRASS databases, Raster_File_Processing for details about raster map layers in GRASS, and Region_and_Mask (???) which discusses regions and masks. The routines in the GIS Library are presented in functional groupings, rather than in alphabetical order. The order of presentation will, it is hoped, provide a better understanding of how the library is to be used, as well as show the interrelationships among the various routines. Note that a good way to understand how to use these routines is to look at the source code for GRASS modules which use them. Most routines in this library require that the header file grass/gis.h be included in any code using these routines. Therefore, programmers should always include this file when writing code using routines from this library:
#include <grass/gis.h>
Note: All routines and global variables in this library, documented or undocumented, start with the prefix G_. To avoid name conflicts, programmers should not create variables or routines in their own modules which use this prefix.
It is mandatory that the system be initialized before any other library routines are called.
G_gisinit() initialize GIS library.
This routine reads the user's GRASS environment file into memory and makes sure that the user has selected a valid database and mapset. It also initializes hidden variables used by other routines. If the user's database information is invalid, an error message is printed and the module exits. The program_name is stored for later recall by G_program_name(). It is recommended that argv[0] be used for the program_name:
The following routines are used by other routines in the library to report warning and error messages. They may also be used directly by GRASS programs.
These routines report errors to the user. The normal mode is to write the message to the screen (on the standard error output). G_warning() will return and G_fatal_error() will exit.
If the standard error output is not a tty device, then the message is mailed to the user instead.
If the file GIS_ERROR_LOG exists (with write permission), in either the user's home directory or in the $GISBASE directory, the messages will also be logged to this file.
While most applications will find the normal error reporting quite adequate, there will be times when different handling is needed. For example, graphics modules may want the messages displayed graphically instead of on the standard error output. If the programmer wants to handle the error messages differently, the following routines can be used to modify the error handling:
This routine provides a different error handler for G_fatal_error() and G_warning(). The <m>handler routine must be defined as follows:
where message is the message to be handled and fatal indicates the type of error:
Note: The handler only provides a way to send the message somewhere other than to the error output. If the error is fatal, the module will exit after the handler returns.
This routine resets the error handling for G_fatal_error() and G_warning() back to the default action.
The following routines return information about the current database selected by the user. Some of this information is retrieved from the user's GRASS environment file. Some of it comes from files in the database itself. See Environment_Variables for a discussion of the GRASS environment.
The following four routines can be used freely by the programmer:
Returns the name of the current database location. This routine should be used by modules that need to display the current location to the user. See Locations for an explanation of locations.
Returns the name of the current mapset in the current location. This routine is often used when accessing files in the current mapset. See Mapsets for an explanation of mapsets.
Returns a one line title for the database location. This title is read from the file MYNAME in the PERMANENT mapset. See also Permanent_Mapset for a discussion of the PERMANENT mapset.
Returns the full path name of the top level directory for GRASS programs. This directory will have subdirectories which will contain modules and files required for the running of the system. Some of these directories are:
bin commands run by the user etc modules and data files used by GRASS commands html help files
The use of G_gisbase() to find these subdirectories enables GRASS modules to be written independently of where the GRASS system is actually installed on the machine. For example, to run the module sroff in the GRASS etc directory:
The following two routines return full path UNIX directory names. They should be used only in special cases. They are used by other routines in the library to build full UNIX file names for database files. The programmer should not use the next two routines to bypass the normal database access routines.
Returns the full UNIX path name of the directory which holds the database locations. See GISDBASE for a full explanation of this directory.
Returns the full UNIX path name of the current database location. For example, if the user is working in location spearfish in the /home/user/grassdata database directory, this routine will return a string which looks like /home/user/grassdata/spearfish.
These next routines provide the low-level management of the information in the user's GRASS environment file. They should not be used in place of the higher level interface routines described above.
These routines look up the variable name in the GRASS environment and return its value (which is a character string). If name is not set, G_getenv() issues an error message and calls exit(). G__setenv() just returns the NULL pointer.
These routines set the the GRASS environment variable name to value. If value is NULL, the name is unset.
Both routines set the value in module memory, but only G_setenv() writes the new value to the user's GRASS environment file.
The routines described in this section provide the low-level interface to the GRASS database. They search the database for files, prompt the user for file names, open files for reading or writing, etc. The programmer should never bypass this level of database interface. These routines must be used to access the GRASS database unless there are other higher level library routines which perform the same function. For example, routines to process raster files (see Raster_File_Processing), vector files (see Vector_File_Processing), etc., should be used instead.
In the descriptions below, the term database element is used. Elements are subdirectories within a mapset and are associated with a specific GRASS data type. For example, raster files live in the "cell" and "fcell" element. See Elements for more details.
All GRASS routines which access database files must be given both the file name and the mapset where the file resides. Often the name and the mapset are 2 distinct character strings. However, there is a need for a single character string which contains both the name and the mapset (e.g., for interactive interfacing to command-line programs). This form of the name is known as the fully qualified file name and is built by the following routine:
Returns a fully qualified name for the file name in mapset Currently this string is in the form name, but the programmer should pretend not to know this and always call this routine to get the fully qualified name.
The following example shows how an interactive version of d.rast interfaces with the command-line version of d.rast:
#include <stdlib.h> #include <grass/gis.h> int main(int argc, char *argv[]) { char name[GNAME_MAX], *mapset, *fqn; char command[1024]; G_gisinit(argv[0]); mapset = G_ask_cell_old("", name); if (mapset == NULL) exit(EXIT_SUCCESS); fqn = G_fully_qualified_name(name, mapset); sprintf(command, "d.rast map='%s'", fqn); G_spawn(command, "d.rast", NULL); exit(EXIT_SUCCESS); }
Command line driven module requires a database file name as one of the command arguments. In this case, the programmer must search the database to find the mapset where the file resides.
The following routines search the database for files:
Look for the file name under the specified element in the database. The mapset parameter can either be the empty string "", which means search all the mapsets in the user's current mapset search path, or it can be a specific mapset, which means. Look for the file only in this one mapset (for example, in the current mapset).
If found, the mapset where the file lives is returned. If not found, the NULL pointer is returned.
If the user specifies a fully qualified file name, (i.e, a name that also contains the mapset; see Fully Qualified File Names) then G_find_file() modifies name by eliminating the mapset from the name.
For example, to find a "paint/labels" file anywhere in the database:
char name[GNAME_MAX]; char *mapset; if ((mapset = G_find_file("paint/labels", name, "")) == NULL) /* not found */
To check that the file exists in the current mapset:
char name[GNAME_MAX]; if (G_find_file("paint/labels", name, G_mapset()) == NULL) /* not found */
Not all names that a user may enter will be legal files for the GRASS databases. The routines which create new files require that the new file have a legal name. If the name is obtained from the command line, the programmer must check that the name is legal. The following routine checks for legal file names:
The following routines open the file name in mapset from the specified database element for reading (but not for writing). The file name and mapset can be obtained using G_find_file().
The database file name under the element in the specified mapset is opened for reading (but not for writing).
The UNIX open() routine is used to open the file. If the file does not exist, -1 is returned. Otherwise the file descriptor from the open() is returned.
The UNIX fopen() routine, with "r" read mode, is used to open the file. If the file does not exist, the NULL pointer is returned. Otherwise the file descriptor from the fopen() is returned.
The following routines open the file name in the current mapset from the specified database element for writing. The file must exist. Its name can be obtained using G_find_file().
The database file name under the element in the current mapset is opened for reading and writing.
The UNIX open() routine is used to open the file. If the file does not exist, -1 is returned. Otherwise the file is positioned at the end of the file and the file descriptor from the open() is returned.
The UNIX fopen() routine, with "a" append mode, is used to open the file. If the file does not exist, the NULL pointer is returned. Otherwise the file is positioned at the end of the file and the file descriptor from the fopen() is returned.
The following routines create the new file name in the current mapset (GRASS does not allow files to be created outside the current mapset; see Database_Access_Rules) under the specified database element and open it for writing. The database element is created, if it does not already exist.
The file name is obtained noninteractively (e.g., from the command line), G_legal_filename() should be called first to make sure that name is a valid GRASS file name. Warning: It is not an error for name to already exist. However, the file will be removed and recreated empty. G_find_file() could be used to see if name exists.
The database file name under the element in the current mapset is created and opened for writing (but not reading).
The UNIX open() routine is used to open the file. If the file does not exist, -1 is returned. Otherwise the file is positioned at the end of the file and the file descriptor from the open() is returned.
The UNIX fopen() routine, with "w" write mode, is used to open the file. If the file does not exist, the NULL pointer is returned. Otherwise the file is positioned at the end of the file and the file descriptor from the fopen() is returned.
The following routines allow the renaming and removal of database files in the current mapset (These functions only apply to the current mapset since GRASS does permit users to modify things in mapsets other than the current mapset; see Database_Access_Rules).
Note: These functions only apply to the specific element and not to other "related" elements. For example, if element is "cell", then the specified raster file will be removed (or renamed), but the other support files, such as "cellhd" or "cats", will not. To remove these other files as well, specific calls must be made for each related element.
The region concept is explained in Region. It can be thought of as a two-dimensional matrix with known boundaries and rectangular cells.
There are logically two different regions. The first is the database region that the user has set in the current mapset. The other is the region that is active in the module. This active module region is what controls reading and writing of raster file data. The vector map export does not take care for the active region settings.
The routines described below use a GRASS data structure Cell_head to hold region information. This structure is defined in the "gis.h" header file. It is discussed in detail under GIS Library Data Structures.
Reading and writing the user's database region are done by the following routines:
Note: Previous versions of GRASS called this the "window". Due to overuse of this term (database window, graphics window, etc.), the term was changed to "region". However, to maintain compatibility with existing programs, library routine names were not changed - hence the term "window" is used in the routine name (where "region" should probably be used instead).
Reads the database region as stored in the WIND file in the user's current mapset into region.
An error message is printed and exit() is called if there is a problem reading the region.
Note: GRASS applications that read or write raster files should not use this routine since its use implies that the active module region will not be used. Programs that read or write raster file data (or vector data) can query the active module region using G_window_rows() and G_window_cols().
Writes the database region file (WIND) in the user's current mapset from region.
Warning: Since this routine actually changes the database region, it should only be called by modules which the user knows will change the region. It is probably fair to say that only the g.region should call this routine.
There is another database region. This region is the default region for the location. The default region provides the user with a "starting" region, i.e., a region to begin with and return to as a reference point. The GRASS modules g.region allow the user to set their database region from the default region (see Permanent_Mapset for a discussion of the default region). The following routine reads this region:
The active module region is the one that is used when reading and writing raster file data. This region determines the resampling when reading raster data. It also determines the extent and resolution of new raster files.
Initially the active module region and the user's database region are the same, but the programmer can make them different. The following routines manage the active module region.
These routines return the number of rows and columns (respectively) in the active module region. Before raster files can be read or written, it is necessary to known how many rows and columns are in the active region. For example:
int nrows, cols; int row, col; nrows = G_window_rows(); ncols = G_window_cols(); for (row = 0; row < nrows; row++) { /* read row ... */ for (col = 0; col < ncols; col++) { /* process col ... */ } }
This routine sets the active region from given region. Setting the active region does not change the WIND file in the database. It simply changes the region for the duration of the module.
However, the new region setting is not retained across the UNIX exec() call. This implies that G_set_window() cannot be used to set the region for a module to be executed using the system() or popen() routines.
Note: This routine overrides the region as set by the user. Its use should be very limited since it changes what the user normally expects to happen. If this routine is not called, then the active region will be the same as what is in the user's WIND file.
Warning: Calling this routine with already opened raster files has some side effects. If there are raster files which are open for reading, they will be read into the newly set region, not the region that was active when they were opened. However, CELL buffers allocated for reading the raster files are not automatically reallocated. The module must reallocate them explicitly. Also, this routine does not change the region for raster files which are open for writing. The region that was active when the open occurred still applies to these files.
Gets the values of the currently active region into region. If G_set_window() has been called, then the values set by that call are retrieved. Otherwise the user's database region is retrieved.
Note: For modules that read or write raster data, and really need the full region information, this routine is preferred over G_get_window(). However, since G_window_rows() and G_window_cols() return the number of rows and columns in the active region, the programmer should consider whether or not the full region information is really needed before using this routine.
Modifies the input region to align to the reference region. The resolutions in region are set to match those in refefence region and the region edges (north, south, east, west) are modified to align with the grid of the reference region.
The region may be enlarged if necessary to achieve the alignment. The north is rounded northward, the south southward, the east eastward and the west westward.
Converts a column relative to a region to an easting.
Note: col is a double: col+0.5 will return the easting for the center of the column; col+0.0 will return the easting for the western edge of the column; and col+1.0 will return the easting for the eastern edge of the column.
Converts a row relative to a region to a northing.
Note: row is a double: row+0.5 will return the northing for the center of the row; row+0.0 will return the northing for the northern edge of the row; and row+1.0 will return the northing for the southern edge of the row.
Converts an easting relative to a region to a column.
Note: The result is a double. Casting it to an integer will give the column number.
Converts a northing relative to a region to a row.
Note: the result is a double. Casting it to an integer will give the row number.
The following routines return information about the cartographic projection and zone. See Region for more information about these values.
This routine returns a code indicating the projection for the active region. The current values are:
Returns a pointer to a string which is a printable name for projection code (as returned by G_projection()).
Returns a string describing the database grid units.
Returns a factor which converts the grid unit to meters (by multiplication). If the database is not metric (eg. imagery) then 0.0 is returned.
This routine returns the zone for the active region. The meaning for the zone depends on the projection. For example zone 18 for projection type 1 would be UTM zone 18.
GRASS supports databases in a longitude-latitude grid using a projection where the x coordinate is the longitude and the y coordinate is the latitude. This projection is called the Equidistant Cylindrical Projection (also known as Plate Carree). ECP has the property that where am I and row-column calculations are identical to those in planimetric grids (like UTM, Universal Transverse Mercator Projection). This implies that normal GRASS registration and overlay functions will work without any special considerations or modifications to existing code. However, the projection is not planimetric. This means that distance and area calculations are no longed Euclidean.
Also, since the world is round, maps may not have edges in the east-west direction, especially for global databases. Maps may have the same longitude at both the east and west edges of the display. This feature, called global wraparound, must be accounted for by GRASS modules (particularly vector based functions, like plotting). What follows is a description of the GIS Library routines that are available to support latitude-longitude databases.
Latitudes and longitudes are specified in degrees. Northern latitudes range from 0 to 90 degrees, and southern latitudes from 0 to -90. Longitudes have no limits since longitudes ±360 degrees are equivalent.
Coordinates are represented in ASCII using the format dd:mm:ssN or dd:mm:ssS for latitudes, ddd:mm:ssE or ddd.mm.ssW for longitudes, and dd.mm.ss for grid resolution. For example, 80:30:24N represents a northern latitude of 80 degrees, 30 minutes, and 24 seconds. 120:15W represents a longitude 120 degrees and 15 minutes west of the prime meridian. 30:15 represents a resolution of 30 degrees and 15 minutes. These next routines convert between ASCII representations and the machine representation for a coordinate. They work both with latitude-longitude projections and planimetric projections.
Note: In each subroutine, the programmer must specify the projection number. If the projection number is PROJECTION_LL (defined in "gis.h"), then latitude-longitude ASCII format is invoked. Otherwise, a standard floating-point to ASCII conversion is made.
Converts the double representation of the given coordinate to its ASCII representation.
Converts the double representation of the resolution to its ASCII representation.
Converts the ASCII coordinate string in to its double representation.
Converts the ASCII "resolution" string to its double representation (into resolution).
The following are examples of how these routines are used.
double north; char buf[50]; G_scan_northing(buf, north, G_projection()); /* ASCII to double */ G_format_northing(north, buf, G_projection()); /* double to ASCII */ G_format_northing(north, buf, -1); /* double to ASCII */ /* This last example forces floating-point ASCII format */
These next routines provide a mechanism for determining the relative position of a pair of longitudes. Since longitudes of ±360 are equivalent, but GRASS requires the east to be bigger than the west, some adjustment of coordinates is necessary.
Returns east larger than west. If the region projection is PROJECTION_LL, then this routine returns an equivalent east that is larger, but no more than 360 degrees larger, than the coordinate for the western edge of the region. Otherwise no adjustment is made and the original east is returned.
This routine returns an equivalent east that is larger, but no more than 360 larger than the west coordinate.
This routine should be used only with latitude-longitude coordinates.
Returns shortest way between eastings.
This routine returns a pointer to a string containing the name for the ellipsoid in the GRASS ellipsoid table. It can be used as follows:
int n; char *name; for(n = 0; name = G_ellipsoid_name(n); n++) fprintf(stdout, "%s\n", name);
This routine returns the semi-major axis (in meters) and eccentricity squared for the named ellipsoid.
This routine returns the semi-major axis (in meters) and the eccentricity squared for the ellipsoid associated with the database. If there is no ellipsoid explicitly associated with the database, it returns the values for the WGS 84 ellipsoid.
Returns the meridional radius of curvature at a given longitude:
Returns the transverse radius of curvature at a given longitude:
Returns the radius of the conformal sphere tangent to ellipsoid at a given longitude:
For latitude-longitude coordinates, this routine determines if the polygon contains one of the poles.
The following routines perform area calculations for raster maps. They are based on the fact that while the latitude-longitude grid is not planimetric, the size of the grid cell at a given latitude is constant. The first routines work in any projection.
This routine must be called once before any call to G_area_of_cell_at_row(). It can be used in either planimetric projections or the latitude-longitude projection.
This routine returns the area in square meters of a cell in the specified row. This value is constant for planimetric grids and varies with the row if the projection is latitude-longitude.
Initializes raster area calculations for an ellipsoid.
Returns the area between latitudes scaled by the factor passed to G_begin_zone_area_on_ellipsoid().
Initializes raster area calculations for a sphere.
Returns the area between latitudes.
These next routines provide area calculations for polygons. Some of the routines are specifically for latitude-longitude, while others will function for all projections.
However, there is an issue for latitude-longitude that does not occur with planimetric grids. Vector/polygon data is described as a series of x,y coordinates. The lines connecting the points are not stored but are inferred. This is a simple, straight-forward process for planimetric grids, but it is not simple for latitude-longitude. What is the shape of the line that connects two points on the surface of a globe?
One choice (among many) is the shortest path from x1,y1 to x2,y2, known as the geodesic. Another is a straight line on the grid. The area routines described below assume the latter. Routines to work with the former have not yet been developed.
This initializes the polygon area calculation routines. It is used both for planimetric and latitude-longitude projections.
Returns the area in square meters of the polygon. It is used both for planimetric and latitude-longitude projections.
Note. If the database is planimetric with the non-meter grid, this routine performs the required unit conversion to produce square meters.
Return the area in map units of the polygon,
This initializes the polygon area calculations for the ellipsoid.
Returns the area in square meters of the polygon for latitude-longitude grids.
Note: This routine assumes grid lines on the connecting the vertices (as opposed to geodesics).
Two routines perform distance calculations for any projection.
Initializes the distance calculations. It is used both for the planimetric and latitude-longitude projections.
This routine computes the distance between two points in meters.
Initializes the distance calculations for the ellipsoid. It is used only for the latitude-longitude projection.
Calculates the geodesic distance between two points in meters.
The calculation of the geodesic distance is fairly costly. These next three routines provide a mechanism for calculating distance with two fixed latitudes and varying longitude separation.
Calculates the geodesic distance between two points set by G_set_geodesic_distance_latl() and G_set_geodesic_distance_lat2().
The following routines form the foundation of a general purpose line and polygon plotting capability.
Draws a line from one point to another using Bresenham's algorithm. A routine to plot points must be provided, as is defined as: point(x, y) plot a point at x,y.
This routine does not require a previous call to G_setup_plot() to function correctly, and is independent of all following routines.
Initializes the plotting capability. This routine must be called once before calling the G_plot_*() routines described below.
Plots line between latlon coordinates. This routine handles global wrap-around for latitude-longitude databases. See G_setup_plot() for the required coordinate initialization procedure.
Plots filled polygon with n vertices. See G_setup_plot() for the required coordinate initialization procedure.
Plots multiple polygons. Like G_plot_polygon(), except it takes a set of polygons, each with n vertices, where the number of polygons is specified with the rings argument. It is especially useful for plotting vector areas with interior islands.
The pixel coordinates x,y are converted to map coordinates east,north. See G_setup_plot() for the required coordinate initialization procedure.
The map coordinates east,north are converted to pixel coordinates x,y.. See G_setup_plot() for the required coordinate initialization procedure.
Often it is necessary for modules to use temporary files to store information that is only useful during the module run. After the module finishes, the information in the temporary file is no longer needed and the file is removed. Commonly it is required that temporary file names be unique from invocation to invocation of the module. It would not be good for a fixed name like "/tmp/mytempfile" to be used. If the module were run by two users at the same time, they would use the same temporary file. In addition systematic use of the /tmp directory could leave the system vulnerable to symlink attacks. The following routine generates temporary file names which are unique within the module and across all GRASS programs.
This routine returns a pointer to a string containing a unique file name that can be used as a temporary file within the module. Successive calls to G_tempfile() will generate new names.
Only the file name is generated. The file itself is not created. To create the file, the module must use standard UNIX functions which create and open files, e.g., creat() or fopen().
The programmer should take reasonable care to remove (unlink) the file before the module exits. However, GRASS database management will eventually remove all temporary files created by G_tempfile() that have been left behind by the modules which created them.
Note: The temporary files are created in the GRASS database rather than under /tmp. This is done for two reasons. The first is to increase the likelihood that enough disk is available for large temporary files since /tmp may be a very small file system. The second is so that abandoned temporary files can be automatically removed (but see the warning below).
Warning: The temporary files are named, in part, using the process id of the module. GRASS database management will remove these files only if the module which created them is no longer running. However, this feature has a subtle trap. Programs which create child processes (using the UNIX fork(), see also G_fork() routine) should let the child call G_tempfile(). If the parent does it and then exits, the child may find that GRASS has removed the temporary file since the process which created it is no longer running.
The following routines provide a standard mechanism for command line parsing. Use of the provided set of routines will standardize GRASS commands that expect command line arguments, creating a family of GRASS modules that is easy for users to learn. As soon as a GRASS user familiarizes himself with the general form of command line input as defined by the parser, it will greatly simplify the necessity of remembering or at least guessing the required command line arguments for any GRASS command. It is strongly recommended that GRASS programmers use this set of routines for all command line parsing. With their use, the programmer is freed from the burden of generating user interface code for every command. The parser will limit the programmer to a pre-defined look and feel, but limiting the interface is well worth the shortened user learning curve.
The GRASS parser is a collection of five subroutines which use two structures that are defined in the GRASS "gis.h" header file. These structures allow the programmer to define the options and flags that make up the valid command line input of a GRASS command.
The parser routines behave in one of three ways:
searches for a completely interactive version of the command. If the interactive version is found, control is passed over to this version.
options and flags that the programmer has defined as required arguments, three things happen. The parser will pass an error message to the user indicating which required options and/or flags were missing from the command line, the parser will then display a complete usage message for that command, and finally the parser cancels execution of the command.
by the user, the parser executes the command with the given options and flags.
The parser routines described below use two structures as defined in the GRASS "gis.h" header file.
This is a basic list of members of the Option and Flag structures. A comprehensive description of all elements of these two structures and their possible values can be found in Full_Structure_Members_Description.
These are the basic members of the Option structure.
struct Option *opt; /* to declare a command line option */
Structure Member Description of Member:
These are the basic members of the Flag structure.
Structure Member Description of Member:
Associated with the parser are five routines that are automatically included in the GRASS Makefile process. The Makefile process is documented in Compiling and Installing GRASS Modules.
Returns Option structure. Allocates memory for the Option structure and returns a pointer to this memory.
Allocates memory for the Flag structure and returns a pointer to this memory.
The command line parameters argv and the number of parameters argc from the main() routine are passed directly to G_parser(). G_parser() accepts the command line input entered by the user, and parses this input according to the input options and/or flags that were defined by the programmer.
G_parser() returns 0 if successful. If not successful, a usage statement is displayed that describes the expected and/or required options and flags and a non-zero value is returned.
Calls to G_usage() allow the programmer to print the usage message at any time. This will explain the allowed and required command line input to the user. This description is given according to the programmer's definitions for options and flags. This function becomes useful when the user enters options and/or flags on the command line that are syntactically valid to the parser, but functionally invalid for the command (e.g. an invalid file name).
For example, the parser logic doesn't directly support grouping options. If two options be specified together or not at all, the parser must be told that these options are not required and the programmer must check that if one is specified the other must be as well. If this additional check fails, then G_parser() will succeed, but the programmer can then call G_usage() to print the standard usage message and print additional information about how the two options work together.
When a user calls a command with no arguments on the command line, the parser will enter its own standardized interactive session in which all flags and options are presented to the user for input. A call to G_disable_interactive() disables the parser's interactive prompting.
Note: Displaying multiple answers default values (new in GRASS 5, see d.zoom for example).
char *def[] = {"One", "Two", "Last", NULL}; opt->multiple = YES; opt->answers = def; if (G_parser(argc, argv)) exit(EXIT_FAILURE);
The programmer may not forget last NULL value.
The use of the parser in the programming process is demonstrated here. Both a basic step by step example and full code example are presented.
These are the four basic steps to follow to implement the use of the GRASS parser in a GRASS command:
(1) Allocate memory for Flags and Options:
Flags and Options are pointers to structures allocated through the parser routines G_define_option() and G_define_flag() as defined in Parser Routines.
#include <grass/gis.h>; /* The standard GRASS include file */ struct Option *opt; /* Establish an Option pointer for each option */ struct Flag *flag; /* Establish a Flag pointer for each option */ opt = G_define_option(); /* Request a pointer to memory for each option */ flag = G_define_flag(); /* Request a pointer to memory for each flag */
(2) Define members of Flag and Option structures:
The programmer should define the characteristics of each option and flag desired as outlined by the following example:
opt->key = "option"; /* The name of this option is "option". */ opt->description = _("Option test"); /* The option description is "Option test" */ opt->type = TYPE_STRING; /* The data type of the answer to the option */ opt->required = YES; /* This option *is* required from the user */ flag->key = "t"; /* Single letter name for flag */ flag->description = _("Flag test"); /* The flag description is "Flag test" */
Note: There are more options defined later in Complete Structure Members Table.
(3) Call the parser:
int main(int argc, char *argv[]); /* command line args passed into main() */ if (G_parser(argc, argv)) /* Returns 0 if successful, non-zero otherwise */ exit(EXIT_FAILURE);
(4) Extracting information from the parser structures:
fprintf(stdout, "For the option "%s" you chose: <%s>\n", opt->description, opt->answer); fprintf(stdout, "The flag "-%s" is %s set.\n", flag->key, flag->answer ? "" : "not");
(5) Running the example program
Once such a module has been compiled (for example to the default executable file a.out , execution will result in the following user interface scenarios. Lines that begin with '$' imply user entered commands on the command line.
$ a.out help
This is a standard user call for basic help information on the module. The command line options (in this case, "help") are sent to the parser via G_parser(). The parser recognizes the "help" command line option and returns a list of options and/or flags that are applicable for the specific command. Note how the programmer provided option and flag information is captured in the output.
a.out [-t] option=name Flags: -t Flag test Parameters: option Option test
Now the following command is executed:
# a.out -t
This command line does not contain the required option. Note that the output provides this information along with the standard usage message (as already shown above):
Required parameter <option> not set (Option test). Usage: a.out[-t] option=name Flags: -t Flag test Parameters: option Option test
The following commands are correct and equivalent. The parser provides no error messages and the module executes normally:
# a.out option=Hello -t # a.out -t option=Hello For the option "Option test" you chose: Hello The flag "-t" is set.
The following code demonstrates some of the basic capabilities of the parser. To compile this code, create this Makefile and run the make command (see Compiling and Installing GRASS Modules).
MODULE_TOPDIR = ../.. PGM = r.mysample LIBES = $(GISLIB) DEPENDENCIES = $(GISDEP) include $(MODULE_TOPDIR)/include/Make/Module.make default: cmd
The sample.c code follows. You might experiment with this code to familiarize yourself with the parser.
Note: This example includes some of the advanced structure members described in Complete Structure Members Table.
#include <stdlib.h> #include <string.h> #include <grass/gis.h> #include <grass/glocale.h> int main(int argc, char *argv[]) { struct Option *opt, *coor; struct Flag *flag; double X, Y; int n; opt = G_define_option(); opt->key = "debug"; opt->type = TYPE_STRING; opt->required = NO; opt->answer = "0"; opt->description = _("Debug level"); coor = G_define_option(); coor->key = "coordinate"; coor->key_desc = "x,y"; coor->type = TYPE_STRING; coor->required = YES; coor->multiple = YES; coor->description = _("One or more coordinate(s)"); /* Note that coor->answer is not given a default value. */ flag = G_define_flag(); flag->key = 'v'; flag->description = _("Verbose execution"); /* Note that flag->answer is not given a default value. */ if (G_parser(argc, argv)) exit (EXIT_FAILURE); G_message("For the option <%s> you chose: <%s>", opt->description, opt->answer); G_message("The flag <%s> is: %s set", flag->key, flag->answer ? "" : "not"); G_message("You specified the following coordinates:"); for (n=0; coor->answers[n] != NULL; n+=2) { G_scan_easting(coor->answers[n], &X , G_projection()); G_scan_northing(coor->answers[n+1], &Y , G_projection()); fprintf(stdout, "%.15g,%.15g", X, Y); } }
<v>struct Flag</v>
| structure member | C type | required | default | description and example |
| key | char | YES | none | Key char used on command line flag->key = 'f' ; |
| Description | char * | YES | none | String describing flag meaning flag->description = _("run in fast mode") ; |
| answer | char | NO | NULL | Default and parser-returned flag states. |
struct Option
| structure member | C type | required | default | description and example |
| key | char * | YES | none | Key word used on command line. opt->key = "map" ; |
| type | int | YES | none | Option type: TYPE_STRING TYPE_INTEGER TYPE_DOUBLE opt->type = TYPE_STRING ; |
| Description | char * | YES | none | String describing option along with gettext macro for internationalization opt->description = _("Map name") ; |
| answer | char * | NO | NULL | Default and parser-returned answer to an option. opt->answer = "defaultmap" ; |
| key_desc | char * | NO | NULL | Single word describing the key. Commas in this string denote to the parser that several comma-separated arguments are expected from the user as one answer. For example, if a pair of coordinates is desired, this element might be defined as follows. opt->key_desc = "x,y" ; |
| structure member | C type | required | default | description and example |
| multiple | int | NO | NO | Indicates whether the user can provide multiple answers or not. YES and NO are defined in "gis.h" and should be used (NO is the default.) Multiple is used in conjunction with the answers structure member below. opt->multiple = NO ; |
| answers | NO | NULL | Multiple parser-returned answers to an option. N/A | |
| required | int | NO | NO | Indicates whether user MUST provide the option on the command line. YES and NO are defined in "gis.h" and should be used (NO is the default.) opt->required = YES ; |
| options | char * | NO | NULL | Approved values or range of values. opt->options = "red,blue,white" ; For integers and doubles, the following format is available: opt->options = "0-1000" ; |
| gisprompt | char * | NO | NULL | Interactive prompt guidance. There are three comma separated parts to this argument which guide the use of the standard GRASS file name prompting routines. opt->gisprompt = "old,cell,raster" ; |
| checker | char *() | NO | NULL | Routine to check the answer to an option m opt->checker = my_routine() ; |
What follows are explanations of possibly confusing structure members. It is intended to clarify and supplement the structures table above.
The answer structure member serves two functions for GRASS commands that use the parser.
(1) To set the default answer to an option:
If a default state is desired for a programmer-defined option, the programmer may define the Option structure member "answer" before calling G_parser() in his module. After the G_parser() call, the answer member will hold this preset default value if the user did not enter an option that has the default answer member value.
(2) To obtain the command-line answer to an option or flag:
After a call to G_parser(), the answer member will contain one of two values:
As an example, please review the use of answer members in the structures implemented in Full Module Example.
The functionality of the answers structure member is reliant on the programmer's definition of the multiple structure member. If the multiple member is set to NO, the answer member is used to obtain the answer to an option as described above.
If the multiple structure member is set to YES, the programmer has told G_parser() to capture multiple answers. Multiple answers are separated by commas on the command line after an option.
Note: G_parser() does not recognize any character other than a comma to delimit multiple answers.
After the programmer has set up an option to receive multiple answers, these the answers are stored in the answers member of the Option structure. The answers member is an array that contains each individual user-entered answer. The elements of this array are the type specified by the programmer using the type member. The answers array contains however many comma-delimited answers the user entered, followed (terminated) by a NULL array element.
For example, here is a sample definition of an Option using multiple and answers structure members:
opt->key ="option"; opt->description = _("option example"); opt->type = TYPE_INTEGER; opt->required = NO; opt->multiple = YES;
The above definition would ask the user for multiple integer answers to the option. If in response to a routine that contained the above code, the user entered "option=1,3,8,15" on the command line, the answers array would contain the following values:
answers[0] == 1 answers[1] == 3 answers[2] == 8 answers[3] == 15 answers[4] == NULL
The key_desc structure member is used to define the format of a single command line answer to an option. A programmer may wish to ask for one answer to an option, but this answer may not be a single argument of a type set by the type structure member. If the programmer wants the user to enter a coordinate, for example, the programmer might define an Option as follows:
opt->key ="coordinate"; opt->description = _("Specified Coordinate"); opt->type = TYPE_INTEGER; opt->required = NO; opt->key_desc = "x,y" opt->multiple = NO;
The answer to this option would not be stored in the answer member, but in the answers member. If the user entered "coordinate=112,225" on the command line in response to a routine that contains the above option definition, the answers array would have the following values after the call to G_parser():
answers[0] == 112 answers[1] == 225 answers[2] == NULL
Note that "coordinate=112" would not be valid, as it does not contain both components of an answer as defined by the key_desc structure member.
If the multiple structure member were set to YES instead of NO in the example above, the answers are stored sequentially in the answers member. For example, if the user wanted to enter the coordinates (112,225), (142,155), and (43,201), his response on the command line would be "coordinate=112,225,142,155,43,201". Note that G_parser() recognizes only a comma for both the key_desc member, and for multiple answers.
The answers array would have the following values after a call to G_parser():
answers[0] == 112 answers[1] == 225 answers[2] == 142 answers[3] == 155 answers[4] == 43 answers[5] == 201 answers[6] == NULL
Note. In this case as well, neither "coordinate=112" nor "coordinate=112,225,142" would be valid command line arguments, as they do not contain even pairs of coordinates. Each answer's format (as described by the key_desc member) must be fulfilled completely.
The overall function of the key_desc and multiple structure members is very similar. The key_desc member is used to specify the number of required components of a single option answer (e.g. a multi-valued coordinate.) The multiple member tells G_parser() to ask the user for multiple instances of the compound answer as defined by the format in the key_desc structure member.
Another function of the key_desc structure member is to explain to the user the type of information expected as an answer. The coordinate example is explained above.
The usage message that is displayed by G_parser() in case of an error, or by G_usage() on programmer demand, is shown below. The Option "option" for the command a.out does not have its key_desc structure member defined.
Usage: a.out option=name
The use of "name" is a G_parser() standard. If the programmer defines the key_desc structure member before a call to G_parser(), the value of the key_desc member replaces "name". Thus, if the key_desc member is set to "x,y" as was used in an example above, the following usage message would be displayed:
Usage: a.out option=x,y
The key_desc structure member can be used by the programmer to clarify the usage message as well as specify single or multiple required components of a single option answer.
The gisprompt Option structure item requires a bit more description. The three comma-separated (no spaces allowed) sub-arguments are defined as follows:
First argument: "old" results in a call to the GRASS library subroutine G_open_old(), "new" to G_open_new(), otherwise "any" or "mapset".
--o (overwrite) flag will be listed in the module's interface (--help output, manual page, GUI dialog, etc).Here are two examples:
"new,cell,raster" G_open_new("cell", "map")
"old,vector,vector" G_open_old("vector", "map")
The gisprompt values are passed to any GUI code, both self-contained dialogs generated by the parser for the --ui option, and stand-alone GUIs (wxGUI) which use the --xml-description flags to obtain a machine-readable description of the module's interface. How the GUI interprets this is up to the GUI.
GRASS 4.0 introduced a new method for driving GRASS interactive and non-interactive modules as described in Compiling_and_Installing_GRASS_Programs. Here is a short overview.
For most modules a user runs a front-end module out of the GRASS bin directory which in turn looks for the existence of interactive and non-interactive versions of the module. If an interactive version exists and the user provided no command line arguments, then that version is executed.
In such a situation, the parser's default interaction will never be seen by the user. A programmer using the parser is able to avoid the front-end's default search for a fully interactive version of the command by placing a call to G_disable_interactive() before calling G_parser() (see Parser Routines for details).
Yes. Options and flags can be given in any order.
Flags and options are presented by the usage message in the order that the programmer defines them using calls to G_define_option() and G_define_flag().
For any user input that requires a set of arguments (like a pair of map coordinates,) the programmer specifies the number of arguments in the key_desc member of the Option structure. For example, if opt->key_desc was set to "x,y", the parser will require that the user enter a pair of arguments separated only by a comma. See the source code for the GRASS commands r.drain or r.cost for examples.
No. Users are required to type in only as many characters of an option name as is necessary to make the option choice unambiguous. If, for example, there are two options, "input=" and "output=", the following would be valid command line arguments:
# command i=map1 o=map2 # command in=map1 out=map2
Yes. There are a few conventions. Options which identify a single input map are usually "map=", not "raster=" or "vector=". In the case of an input and output map the convention is: "input=xx output=yy". By passing the 'help' option to existing GRASS commands, it is likely that you will find other conventions. The desire is to make it as easy as possible for the user to remember (or guess correctly) what the command line syntax is for a given command.
This section describes some routines which perform string manipulation. Strings have the usual C meaning: a NULL terminated array of characters.
These next 3 routines remove unwanted white space from a single string.
Leading and trailing white space is removed from the string and internal white space which is more than one character is reduced to a single space character. White space here means spaces, tabs, linefeeds, newlines, and formfeeds.
Leading and trailing white space is removed from the string. White space here means only spaces and tabs. There is no return value.
Chop leading and trailing white spaces: space, \f, \n, \r, \t, \v.
The next routines replaces character(s) from string.
Replace all occurencies of character in string with new.
This next routine copies a string to allocated memory.
This routine allocates enough memory to hold the string, and returns a pointer to the allocated memory.
The next 2 routines convert between upper and lower case.
Upper case letters in the string are converted to their lower case equivalent.
Lower case letters in the string are converted to their upper case equivalent.
This routine remove trailing zeros from decimal number for example: 23.45000 would come back as 23.45.
Get position of delimiter.
String compare ignoring case (upper or lower).
Return a pointer to the first occurrence of subString in mainString, or NULL if no occurrences are found.
Returns a pointer to a string that is a duplicate of the string given to G_strdup. The duplicate is created using malloc. If unable to allocate the required space, NULL is returned.
A number of useful UNIX library routines have side effects which are sometimes undesirable. The routines here provide the same functions as their corresponding UNIX routine, but with different side effects.
The standard UNIX fork() routine creates a child process which is a copy of the parent process. The fork() routine is useful for placing a module into the background. For example, a module that gathers input from the user interactively, but knows that the processing will take a long time, might want to run in the background after gathering all the input. It would fork() to create a child process, the parent would exit() allowing the child to continue in the background, and the user could then do other processing.
However, there is a subtle problem with this logic. The fork() routine does not protect child processes from keyboard interrupts even if the parent is no longer running. Keyboard interrupts will also kill background processes that do not protect themselves.
Note: Programmers who use Bash know that programs run in the background (using & on the command line) are not automatically protected from keyboard interrupts. To protect a command that is run in the background, Bash users must do nohup command &. Programmers who use the C Shell (or other variants) do not know, or forget that the C-shell automatically protects background processes from keyboard interrupts.
Thus a module which puts itself in the background may never finish if the user interrupts another module which is running at the keyboard.
The UNIX system() call allows one program, the parent, to execute another UNIX command or module as a child process, wait for that process to complete, and then continue. The problem addressed here concerns interrupts. During the standard system() call, the child process inherits its responses to interrupts from the parent. This means that if the parent is ignoring interrupts, the child will ignore them as well. If the parent is terminated by an interrupt, the child will be also.
Note that code which uses system() or popen() tends to be error-prone, particularly on Windows. We strongly discourage anyone from using either system() or popen() in the GRASS code. If you don't need to communicate with the child process via a pipe, you can use G_spawn() or G_spawn_ex(). These provide similar functionality to system() but without the shell getting in the way (using the shell creates problems if filenames or other arguments contain spaces or other characters which are significant to the shell). If you need to communicate via a pipe, you can either use G_spawn_ex() and manage the pipe yourself, or use popen(). See also G_popen_read() and G_popen_write() which do most of the work for you. Alternatively, you can use a temporary file rather than a pipe for communicating with the child process.
To test if the user's machine is little or big ENDIAN, the following function is provided:
Test if machine is little or big endian.
A number of general purpose routines have been provided.
Returns a pointer to a string which is the current date and time. The format is the same as that produced by the UNIX date command.
Returns a pointer to a string which is the full path name of the user's home directory.
This routine prints a percentage complete message to stderr. Example:
#include<grass/gis.h> #include<grass/glocale.h> int row; int nrows; nrows = 1352; /* 1352 is not a special value - example only */ G_message(_("Percent complete:")); for (row = 0; row < nrows; row++) G_percent(row, nrows, 10);
This will print completion messages at 10% increments; i.e., 10%, 20%, 30%, etc., up to 100%. Each message does not appear on a new line, but rather erases the previous message. After 100%, a new line is printed.
Routine returns the name of the module as set by the call to G_gisinit().
Returns a pointer to a string which is the user's login name.
Some of the data structures, defined in the "gis.h" header file and used by routines in this library, are described in the sections below.
The raster header data structure is used for two purposes. It is used for raster header information for map layers. It also used to hold region values. The structure is:
struct Cell_head { int format; /* max number of bytes per cell minus 1 */ int compressed; /* 0 = uncompressed, 1 = compressed, -1 pre 3.0 */ int rows; /* number of rows in the data 2D */ int rows3; /* number of rows in the data 3D */ int cols; /* number of columns in the data 2D */ int cols3; /* number of columns in the data 3D */ int depths; /* number of depths in data */ int proj; /* projection (see #defines above) */ int zone; /* projection zone */ double ew_res; /* east to west cell size 2D */ double ew_res3; /* east to west cell size 3D */ double ns_res; /* north to south cell size 2D */ double ns_res3; /* north to south cell size 3D */ double tb_res; /* top to bottom cell size */ double north; /* coordinates of map layer */ double south; double east; double west; double top; double bottom; };
The format and compressed fields apply only to raster headers. The format field describes the number of bytes per raster data value and the compressed field indicates if the raster file is compressed or not. The other fields apply both to raster headers and regions. The geographic boundaries are described by north, south, east and west. The grid resolution is described by ew_res and ns_res. The cartographic projection is described by proj and the related zone for the projection by zone. The rows and cols indicate the number of rows and columns in the raster file, or in the region. See Raster Header File for more information about raster headers, and Region for more information about regions.
The routines described in Raster Header File use this structure.
The Categories structure contains a title for the map layer, the largest category in the map layer, an automatic label generation rule for missing labels, and a list of category labels.
struct Categories { CELL ncats; /* total number of categories */ CELL num; /* the highest cell values. Only exists for backwards compatibility = (CELL) max_fp_values in quant rules */ char *title; /* name of data layer */ char *fmt; /* printf-like format to generate labels */ float m1; /* multiplication coefficient 1 */ float a1; /* addition coefficient 1 */ float m2; /* multiplication coefficient 2 */ float a2; /* addition coefficient 2 */ struct Quant q; /* rules mapping cell values to index in list of labels */ char **labels; /* array of labels of size num */ int *marks; /* was the value with this label was used? */ int nalloc; int last_marked_rule; };
This structure should be accessed using the routines described in Raster Category File.
The color data structure holds red, green, and blue color intensities for raster categories. The structure has become so complicated that it will not be described in this manual.
struct Colors { int version; /* set by read_colors: -1=old, 1=new */ DCELL shift; int invert; int is_float; /* defined on floating point raster data? */ int null_set; /* the colors for null are set? */ unsigned char null_red; unsigned char null_grn; unsigned char null_blu; int undef_set; /* the colors for cells not in range are set? */ unsigned char undef_red; unsigned char undef_grn; unsigned char undef_blu; struct _Color_Info_ fixed; struct _Color_Info_ modular; DCELL cmin; DCELL cmax; int organizing; };
The routines described in Raster Color Table must be used to store and retrieve color information using this structure.
The History structure is used to document raster files. The information contained here is for the user. It is not used in any operational way by GRASS. The structure is:
# define MAXEDLINES 50 # define RECORD_LEN 80 struct History { char mapid[RECORD_LEN]; char title[RECORD_LEN]; char mapset[RECORD_LEN]; char creator[RECORD_LEN]; char maptype[RECORD_LEN]; char datsrc_1[RECORD_LEN]; char datsrc_2[RECORD_LEN]; char keywrd[RECORD_LEN]; int edlinecnt; char edhist[MAXEDLINES][RECORD_LEN]; };
The mapid and mapset are the raster file name and mapset, title is the raster file title, creator is the user who created the file, maptype is the map type (which should always be "raster"), datasrc_1 and datasrc_2 describe the original data source, keywrd is a one-line data description and edhist contains edlinecnt lines of user comments.
The routines described in Raster History File use this structure. However, there is very little support for manipulating the contents of this structure. The programmer must manipulate the contents directly.
Note: Some of the information in this structure is not meaningful. For example, if the raster file is renamed, or copied into another mapset, the mapid and mapset will no longer be correct. Also the title does not reflect the true raster file title. The true title is maintained in the category file.
Warning: This structure has remained unchanged since the inception of GRASS. There is a good possibility that it will be changed or eliminated in future releases.
The Range (FPRange for floating point raster maps) structure contains the minimum and maximum values which occur in a raster file.
struct Range { CELL min; CELL max; int first_time; /* whether or not range was updated */ }; struct FPRange { DCELL min; DCELL max; int first_time; /* whether or not range was updated */ };
The routines described in Raster Range File should be used to access this structure.
The library is loaded by specifying in the Makefile. The following example is a complete Makefile which compiles code that uses this library:
Makefile for
MODULE_TOPDIR = ../.. PGM = r.info LIBES = $(GISLIB) DEPENDENCIES = $(GISDEP) include $(MODULE_TOPDIR)/include/Make/Module.make default: cmd
See Compiling and Installing GRASS Modules for a complete discussion of Makefiles.
This structure is defined in "gis.h", but there should be no reason to access its elements directly:
Using the G_*_timestamp() routines reads/writes a timestamp file in the cell_misc/rastername mapset element.
A TimeStamp can be one DateTime, or two DateTimes representing a range. When preparing to write a TimeStamp, the programmer should use one of:
Use to copy the TimeStamp information into Datetimes, so the members of struct TimeStamp shouldn't be accessed directly.
Sets ts->count = 0, to indicate no valid DateTimes are in TimeStamp.
Copies a single DateTime to a TimeStamp in preparation for writing (overwrites any existing information in TimeStamp).
Copies two DateTimes (a range) to a TimeStamp in preparation for writing (overwrites any existing information in TimeStamp).
Only timestamp files in current mapset can be removed.
See DateTime_Library for a complete discussion of GRASS datetime routines.
The following routines provide memory allocation capability. They are simply calls to the UNIX suite of memory allocation routines malloc(), realloc() and calloc(), except that if there is not enough memory, they print a diagnostic message to that effect and then call exit().
Allocates a block of memory at least size bytes which is aligned properly for all data types. A pointer to the aligned block is returned.
Changes the size of a previously allocated block of memory at ptr and returns a pointer to the new block of memory. The size may be larger or smaller than the original size. If the original block cannot be extended "in place", then a new block is allocated and the original block copied to the new block.
Note: If ptr is NULL, then this routine simply allocates a block of size bytes. This routine works around broken realloc() routines, which do not handle a NULL ptr.
Allocates a properly aligned block of memory n*size bytes in length, initializes the allocated memory to zero, and returns a pointer to the allocated block of memory.
Use the G_free() routine to release memory allocated by these routines.
1.8.0