Caribbean Disaster Mitigation Project
Implemented by the Organization of American States
Unit of Sustainable Development and Environment
for the USAID Office of Foreign Disaster Assistance and the Caribbean Regional Program

USAID Logo OAS Logo

Exchanging Information Between
the SPANS and IDRISI GIS Programs

Note: This document was extracted from the GIS Handbook for Dominica, prepared by CDMP.

This section of the handbook contains material developed at a special workshop with PPU. This special workshop took place at the office of PPU, in Roseau, Dominica, during the week after the Workshop on GIS and Utilities. The emphasis was on system management, practical help for a team that already has a large GIS and faces the problems of keeping it working.

File names, directory names, and file formats will be in bold. In addition, quotation marks will be used the first time a file is mentioned in the text. Commands to be executed inside a software package will be presented as a sequence of menu names, such as "File/Import/Vector."

Contents

Hints for Using SPANS

SPANS uses many different formats for its files, but the most important distinction is between files that must be used in a specific "study area" and files that can be moved around from one study area to another. We will refer to the first kind of files as "internal files" and the second kind we will call "export format files."

SPANS file formats: an incomplete listing
Purpose Internal files Export format files
set the projection, geoid, extents, classification schemes, legends, windows, and other parameters of a study area curparam.dat
spans.key
sysdef.dat
spans.dat
etc.
Library files
tabular data (often linked to vector data) *.tbb (a binary format) *.tba (an ASCII format)
vector data, including

points, lines, and/or polygons

*.vtx (locates the points)
*.top (tells how they are connected)
*.vec (the data, in ASCII)
*.veh (a header file, describing the vector data)
quadtree data *.map No equivalent
raster data *.rnl (the data) *.rnl (same file)
*.rnh (describing the data, in ASCII)

So why is SPANS so complicated? Believe it or not, it is supposed to save storage space. The geographic parameters for a study area are set just once, in "curparam.dat." Other basic parameters are also set in the basic files of the study area. The data, then, is in a set of compact, binary files which refer to the coordinate system of the study area, and which do not duplicate any other information.. The quadtree maps are especially compact, but they can not be taken away from the study area.

SPANS is conceived as an records system, with a great deal of information saved for the long term with rigourous georeferencing and quick access.. The vector sets, tables, and quadtrees of a study area are supposed to work together as a spatial database. Properly managed, such a database would allow you to make queries such as, "How many house lots will touch on a pipeline if we run it on the east side of the road?"

This data structure can serve the purposes of Physical Planning Unit, if you proceed methodically:

For example, someone has digitized all the roads of Dominica. During the digitizing, there were various files created (No, they are not listed above) but the only ones that matter are the final result, files named "roads.vec" "roads.veh" and, if the digitizing included database information, a file named "roads.tba."

Suppose you create a new study area, called "Picard." It has a basemap covering from Portsmouth south to Petite Baie. You copy the vector file set Roads.* to the Picard directory and then, in SPANS, you do File/Import/Lines/roads.

That command uses roads.veh and roads.vec to create roads.top and roads.vtx in the study area of Picard. Roads.tba, if it is there, gets converted into roads.tbb. Now your study area has the portions of the roads that fall within your basemap. The rest of the original files (*.vec ,*.veh, *.tba) are either irrelevant or redundant. Erase them. From Picard. (Remember, you left the originals in the common directory, right?)

SPANS file maintenance

Hints for using IDRISI

By contrast with SPANS, IDRISI is conceived as a modeling and image-processing software. Individual files may be created and destroyed much more freely, georeferencing is kept for each file, and record-keeping is simple. If you ask IDRISI to list your maps, it reads the hard drive for the current subdirectory at that very moment. Similarly, if you open an IDRISI module such as "display" and the module needs to tell you what maps are available to display, IDRISI reads the hard drive again. IDRISI does not keep internal lists or file formats limited to an individual study area.

Notes:

PROJECTION is a line indicating that the study area uses the 3rd choice of projection and the 7th choice of ellipsoid. That corresponds to UTM, Clarke 1886, central meridian = 63 degrees west of Greenwich, central scale 0.9996 of true scale, false X coordinate is 500,000 at the central meridian, Y coordinate is 0 at the equator

GEO_REFERENCE is a line indicating that the raster cells are in meters, 7.933etc meters on a side, and the lower left corner has the UTM coordinates set to (0,0) instead of X= 661,135 and Y=1,681,044

There are quite a few file formats for IDRISI, but you will only need one or two types at a time for anything you try to do. The most common are:

IDRISI file formats: selected types
Purpose Format
vector data, including points, lines, and/or polygons *.dvc (ASCII documentation of the vector data)
*.vec (ASCII, long list of numbers)
rasters *.doc (ASCII documentation of the raster)
*.img (ASCII rarely, usually binary, list of numbers)

Physical Planning Unit can continue to use SPANS as the central archive and geographic data base. IDRISI, then, will be a toolbox for spatial modeling and analysis of remote sensing. The data to use in IDRISI will be exported from and imported back into SPANS.

Moving Files from SPANS to IDRISI

Both of these software packages have long lists of format translators. Feel free to experiment with them, but be forewarned that translation is a tricky business. Below is a description of some operations that seem to work well.

First, you will need to establish a SPANS study area with all the data layers you wish to export. This is the simplest way to make sure that the rasters and vectors have the same georeferencing, and that they fit with each other. Darrell Edgett favoured the UTM projection and the Clarke 1886 ellipsoid when he set up many of the files for Dominica, so you are safe using those.

For raster files, plan ahead:

Now, there is a little bit of custom work to do. The raster header file contains information you need, so make a paper copy or bring it into Notepad to read it.. The next page contains a raster header file, in large print, with some pointers for interpreting it .

To bring this raster into IDRISI,

Try Display/Display Launcher/ to show the raster you just documented. If the raster looks skewed, like coloured stripes all leaning to the left or to the right, then you used the wrong numbers of rows and columns. If the raster looks right, you still have to check the georeferencing. The quickest check on georeferencing is to overlay a vector file, so see below.

For vector files, the utilities do almost all of the work:

Now you can display the vector over the raster from the same study area and see if they fit each other.

Moving Files from IDRISI back to SPANS

For Rasters: If you have maps in IDRISI that derived from a SPANS *.rnl, and if you have not changed the number of rows and columns, then you can customize the original *.rnh to bring the data home to SPANS:

If you have changed the extents of the image data while in IDRISI, either by Window, Reformat/Contract/ or some other resampling command, you can probably get the new information into SPANS. Try altering a *.rnh file to show the new extents. Or, you can add rows and columns to the edges of the windowed images using Reformat/Concat. Or you can use Reformat/Expand to reverse the effects of Contract. The philosophy is the same: if the georeferencing has been preserved, we can recreate the header file.

An alternative approach is to convert the image to vectors. This is only appropriate with simple images that have a few values grouped in distinct areas. In other words, if the image looks like simple polygons, then a conversion to polygons might work. The commands in IDRISI are under Reformat/Raster-Vector Conversion. Then you can use the data translators for MapInfo format, or any others that you discover will work.

This document was prepared for the CDMP and the workshop was presented by Ross Wagenseil, [email protected]

References

These two workshops were organized around the SPANS and IDRISI software packages, which are distributed under license. For licenses or manuals, contact:

CDMP home page: http://www.oas.org/en/cdmp/ Project Contacts Page Last Updated: 20 April 2001