Untitled

GED User's Guide

GRASS IMPLEMENTATION

GETTING STARTED

To import raster data into GRASS from the current DOS/Idrisi-structured databases use one of two methods. The most convenient method, for those who use Idrisi, is to use the IDRGRASS conversion utility and instructions. The files will be created in the correct structure and can then be transferred into the GRASS/UNIX system using any binary file transfer method (which will preserve the binary formats created by the conversion process). The user may need to edit the resultant "cellhd" files for GRASS version compatibility. See examples given below for ideas on how to do this.

The second method is to access the data directly from UNIX. GRASS "cellhd" (header) files will need to be constructed from the system metadata using the GRASS function r.support, an editor, or other suitable programming tools. Alternatively, the user may refer to the GRASS Programmer's Manual for the relatively straightforward procedure for developing the required "cellhd" files. Problems arising in the numerical formats of the data because of differences between DOS and UNIX configurations are discussed in the User's Guide, in the section on Data Storage Formats.

The 8-bit raster grid files in the database are identical to uncompressed GRASS cell files. They can be ported directly into a GRASS cell subdirectory and used with the appropriate headers (either manually created using the examples below or created using GRASS function r.support).

The 16-bit integer raster grid files are another matter. GRASS has a non-standard manner of handling data with values over 255 (i.e., two-byte integers) and signed integers. GRASS users will have to convert the 16-bit (two byte integer) data into a GRASS compatible form on import to GRASS.

GRASS databases allow for mixed pixel sizes, geo-referencing, and differing image coverage within a database. Thus GRASS will support the use of all GED data on either their original grids (i.e., in the 'source' directory) or the 'nested' grids of the GED (i.e., in the 'glgeo' directory). GRASS will also automatically re-sample a dataset ("on-the-fly") to whatever window and grid size the user specifies. However, this flexible overlay and re-sampling capability of GRASS, though convenient, has a drawback: Without careful attention to detail, the GRASS user may easily misrepresent a dataset through GRASS' automatic (and transparent) interpolation to a user-defined grid. This can be avoided by standardizing the default grid and window to one of the 'nested' grids used in this database, or by being careful in setting GRASS' working region with the g.region command.

GRASS Implementation

CAUTION!

As with any GIS, the user must be aware that coarser-grid data, when represented on a finer grid ('nested' or not) retains its original spatial definition. For example, if the user chooses to work on a 10-minute grid using the GVI data, and access a .5 degree dataset in an overlay operation, combining .5 degree spatial statistics with 10-minute spatial statistics, the results can only be evaluated in the context of the user's requirements, and the documented statistical meaning of the data (e.g., cell average, point sample, spatial mode, class value, etc.).

If, on the other hand, the choice is to work at a coarser grid than some of the data that will be used, the problem of aggregation is introduced when accessing the finer-grid data. In this case, it is advised to first re-interpret all datasets onto the coarser grid, using appropriate methods and documentation unique to each dataset. A variety of tools are available in Idrisi, GRASS, or other GISs to accomplish this, again, according to the user's requirements.

GRASS Implementation

ACCESS PROCEDURE FROM UNIX SYSTEMS

Please refer to the User's Guide for documentation of the default data structures in the database. The file formats are simple, and are based partly on defacto standards of data exchange.

RASTER FILES

With the above cautions in mind, the standard way to import a binary raster grid into GRASS is:

Import the grid file into the "cell" subdirectory of the user's database,
Make a cell header file in the "cellhd" subdirectory (this can also be made in step 3 below),
Run "r.support" to make other associated files.

The procedure has several slight variations:

If using GRASS 4.x or earlier version of GRASS,
If using the latlon projection (i.e., all data in glgeo), "unprojected" pixel-space, or UTM projections
If the data are 8 or 16bit binary grids,
If the user wants to use the data directly from the online database.

The discussion below describes how to handle these variations.

IMPORTING AN 8BIT RASTER DATA FILE INTO GRASS

An 8bit GRASS grid file is identical to 8bit binary .img files provided in the GED. To use GED .img files in GRASS, copy the files to the "cell" file subdirectory as the new GRASS GLOBAL/PERMANENT (or whatever) database, and remove the .img extension. Edit sample cell header files into the "cellhd" subdirectory of the user's GLOBAL database. Sample "cellhd" file formats are as follows:

For GRASS 3.x, y use the X,Y "unprojected" projection, although a few GRASS 3.x users may have a version that supports the latitudelongitude projection. A sample 3.x header is:

proj: 0
zone: 1
north: 0
south: 1080
west: 0
east: 2160
ew resol: 1
ns resol: 1
format: 0
compressed: 0

This sample header will work for all 10minute unprojected 8bit binary raster data files. It is worth making a sample header file called "basic.10min" like this, and place it into the "cellhd" directory. Every time a 10minute 8bit binary data file is imported into GRASS from the GED, the file a name (such as gvioct86) is given for the grid file in the "cell" directory. Then go to the "cellhd" directory, execute the command;

cp basic.10min gvioct86

to make the appropriate cell header file for the new dataset.

Global raster datasets with different raster cell sizes usually have identical cell header files, except for the "ew resol:" and the "ns resol:" entries. Instead of "1" for the 10minute gridded data, use 3 for 30minute grids, 6 for 1degree grids, 12 for 2degree grids, .2 for 2minute grids, etc. All other parts of the cell header file remain unchanged, for 8bit data. Again, it is worth making sample "basic.2min", "basic.30min", "basic.1deg". etc., cell header files to use when importing data from the GED.

For Grass 4.x, the "unprojected" projection can be used, with a header as shown above. If both GRASS 3.x and GRASS 4.x are used, retain a common georeferencing, especially if the user is going to use vector files as well as raster files. However, if only GRASS 4.x is used, the latitudelongitude projection may be preferred. A sample 4.x header in latitudelongitude is:

proj: 3
zone: 0
north: 90N
south: 90S
west: 180W
east: 180E
cols: 2160
rows: 1080
ew resol: 0:10
ns resol: 0:10
format: 0
compressed: 0

Note that data at resolutions other than 10 minutes would have to have the "cols:", "rows:", "ew resol:", and "ns resol:" categories modified accordingly. A one-degree dataset would have 360, 180, 1:00 and 1:00, respectively, for these parameters.

Note that cell header files have identical names as raster data files that they describe. GRASS separates different types of files into different subdirectories, but keeps the same names for all files that relate to a given data layer. See the GRASS 3.0 or the GRASS 4.0 Programmer's Reference Manual, available from the U. S. Army Corps of Engineers, for information on GRASS directory structures (http://www.cecer.army.mil/grass).

Finally: After importing (or linking) the 8bit raster data to the "cell" directory and creating cell header files, run the GRASS command that completes the ingest of a data layer (in GRASS 4.x this is r.support; in GRASS 3.x the program is called support). Follow the function as prompted. Data are now imported into GRASS.

IMPORTING A 16BIT RASTER DATA FILE INTO GRASS

GRASS' 16bit data format is designed for the "ultimate" in portability between UNIX workstations, not all of which handle integer data in the same way. The GRASS multibyte format is described in the GRASS Programmer's Manual. This format is not "industry standard," and necessitates conversion of the data. The conversion procedure is relatively straightforward.

First, check to see if the integer data must be byte swapped. As a rule of thumb, if the UNIX workstation uses Intellike integers (such as most IBMcompatible PCs or Digital Equipment VAX computers running UNIX), no byte swapping is necessary. If the UNIX workstation is based on a Motorola processor, on a RISC processor in a similar family of workstations, byte swapping is likely. If the user must swap bytes, run the following command (Check the exact syntax for the user's computer):

dd if=infile of=outfile conv=swab

where infile is the 16bit file that must be converted, such as FNOCMOD on the GED. In this case, copy FNOCMOD to the "cell" directory of the hard disk, calling the output file infile.

Next, create cell header files using the same procedure described under importing 8bit data files. The only change is in the "format:" line in the cell header files. For 8bit files this should be 0. For 16bit files, this should be a 1.

Next, run support (r.support in GRASS 4.x) to make the associated files.

The resultant 16bit dataset is properly imported into GRASS except for the conversion from 2byte integer to GRASS' multibyte format. This is accomplished in two steps:

First, to ensure that the user is working on the entire global database, rather than a local or regional window, run window (g.region in GRASS 4.x). Set the window/region to global. This can be done in many ways. If the "default_wind" file (describing the default working window/region) is already set to global, reset the working window/region to the user's default window. Otherwise, manually edit the window/region, or run the command:

g.region rast=globalfile

where "globalfile" is any previously-ingested fully global file (8- or16-bit) with the correct cell size..

Second, run r.mapcalc (in GRASS4.x, Gmapcalc in Grass3.x) with the following syntax:

r.mapcalc 'outfile = if(infile32768,infile65536,infile,infile)'

where infile is the 16bit integer raster data file from the GED (byteswapped, if necessary), and outfile is the file converted to GRASS multibyte format. Name the output file anything the user chooses. In this example, since FNOCMOD data are imported, this name is used again for the final GRASS version of the data.

This procedure may not work for some UNIX workstations.

VECTOR FILES

The vector data provided here are in .vec files, with .dvc header files. The .vec files are in ASCII, and are akin to the files produced by digitizers. As such, they are easily modifiable in a word processor, or in a database management system. Converting the data in this way, the user should be able to match an ASCII vector file or digitizer file format, if the user's GIS handles vector or digitized data. The files in this example have been converted to GRASS, and to OSU MAPforthePC format using a word processor. (Note: a text-based editor or word processor that shows the literal contents of the file is much easier to use for such work than a graphical [WYSIWYG] word processor.( GRASS takes ASCII data in a welldocumented format and converts them to binary vector files. These files can be rasterized, or used in GRASS in their vector format. OSU MAPforthePC takes ASCII digitizer files and rasterizes them.

A word of caution: Idrisi vector files use the bottomleft corner as the origin, whereas Idrisi raster files use the topleft corner as the origin. It may therefore be necessary to subtract 1080 from the Y coordinate, then multiply the Y coordinate by 1 to convert the coordinates. This can be done with a word processor that permits mathematical operations on numerical data, and which has a column mode. Otherwise, a word processor can be used to reconfigure the vector file format (from its two interleaved line formats to a uniform fourcolumn format), and a database management system can be used to convert the coordinates (with a reconversion to back to the GIS's vector file format in the DBMS or word processor).

The vector data on the GED, are all line segments with the following format:

This file has two line segments. The first line segment has attribute class value 245 and is described by four X,Y (or horizontal position, vertical position) pairs. The second has attribute class value 248 and is described by two X,Y pairs. The bottom line (two zeros) marks the end of the file.

The ASCII version of a GRASS vector file resides in the dig_ascii subdirectory of the GLOBAL (or whatever) database. It has the format shown below;

where 'L' stands for line segment ('A' would denote a polygonal area). The number to the right of the 'L' denotes the number of Y,X (vertical position, horizontal position) pairs that describe the line segment.

The coordinates must be in the same units and projection as the raster database. This may entail conversion from the units used on the GED. For example, for GED vector files stored in arcminutes of latitude and longitude, will be OK if the raster database also uses multiples of arcminutes. If units need to be converted, many word processors or database management systems can import, convert, and re-export data from these ASCII files fairly easily.

Note then, to convert the data from the GED to GRASS, the attribute class value is changed to L or A as appropriate, and the columns of X,Y pairs are exchanged to make the Y,X pairs of the file in the GRASS dig_ascii subdirectory. The attribute class value is assigned as follows:

GRASS stores the attribute class value not in the dig_ascii subdirectory, but in a separate category file (with the same name) stored in the dig_att subdirectory. This file has the following format:

L 622 6272 245
L 1062 6382 2487

This is in the format of feature identifier (L or A), Y coordinate, X coordinate, and attribute. If a line segment in the vector file has no associated category in this file, it is considered unlabelled. This means that during a vectortoraster conversion, such areas will be converted to category zero, and such lines will be ignored.

The L stands for a line segment, the Y and X positions are markers (which must be inside a polygonal area, or closer to a line segment than to any other line segment but not at a node.

Given the files in the dig_ascii and dig_att subdirectories, run v.import (in GRASS 4.x, import.to.vect in GRASS 3.x), answering the prompts, to convert the data to binary vector files that GRASS uses in its processing.

The units given for the vector files are in pixel-space. If the user wants the vector date in a latitude-longitude GRASS database, they must first be put into a pixel-space database, then run v.project to convert them to latitude-longitude. See the GRASS Users' Guide description of v.project for details of this procedure. The GRASS User's Guide,Programmer's Reference Manual, source code, sample data, and more are available on the GRASS website at http://www.cecer.army.mil/grass, and/or the new GRASS site at Baylor University (http://www.baylor.edu/~grass).

Return to top of GRASS Implementation