@title{GDB}{Generic Database Reference} PCI's Works programs, and some PACE programs use the Generic DataBase library (GDB) to access image and auxiliary information from data files. This allows different file types to be used interchangeably where it makes sense for the file type. Most file types do not support all types of possible data and access. In fact only PCIDSK files support all possible data types. The following topics will discuss the level of support and user implementation details for each of the supported file types. 1 Supported File Formats @keyword{Formats!Supported} The following file types are supported by the Generic DataBase library. 2 ADRG @index{ADRG CD-ROM} @keyword{ADRG}{DIGEST}{CDROM}{CD-ROM} ADRG, a specific form of "DIGEST" data distributed on CD-ROM is supported by the GDB layer. ADRG CD-ROMs typically contain 3 image channels and one or more images. Users should select the ".GEN" file which is located in a subdirectory on the disk. The name of this subdirectory varies with each disk. An example name is "/cdrom/jaus0101/jaus0101.gen". To select an image other than the default image, the image number is specified as if it were a file in the ".GEN" file's directory. As an example, "/cdrom/cous0101/cous0101.gen/2" would select the second file on a disk. Georeferencing information is gathered from the disk, but other text and descriptive information is not. Writing an ADRG disk is not supported by the GDB layer. See Also: FIMPORT 2 Arc/Info Generate @index{Arc/Info!Generate}{Generate (ArcInfo)} @keyword{Arc/Info Generate} Arc/Info Generate (or Ungenerate) files are supported by the GDB library. They are represented as a single vector segment, with no other auxiliary information. Generate files contain no georeferencing information so the vectors are assigned a georeferencing type of METRE. Generate files contain one numeric attribute which is imported and exported with the vector data. Generate files may be created by Works programs, and the FEXPORT PACE program. Also, the PACE programs VECREAD and VECWRIT may be used to access Generate files, although these programs are not as reliable as FIMPORT and FEXPORT. See Also: {WORKS|Data File|File Creat}Works Create File, VECREAD, VECWRIT, FIMPORT, FEXPORT, {..|Arc/Info GRID}Grid 2 Arc/Info Grid @index{Arc/Info!Grid} @keyword{Arc/Info Grid} Arc/Info ASCII Grid files are supported by the GDB library. These are files in the format compatible with the Arc/Info ASCIIGRID and GRIDASCII commands, and consists of one raster layer. Currently the ASCII Grid format is only supported for importing into EASI/PACE, and the raster layer is always represented as 16 bit signed. It is likely that floating point grid files will not work at all. If a ``.prj'' file is in the same directory as the grid file, and has the same basename as the grid file it will be read to obtain projection information. Currently the only recognised projecion is UTM. All other files will be imported with a MAPUNITS string of ``METRE''. Is is not possible to LINK to Grid files as they are ASCII encoded. See Also: FIMPORT, {..|Arc/Info Generate}Generate 2 Arc/Info Import/Export @index{Arc/Info!Import} @index{Arc/Info!Export} @keyword{Arc/Info Import} @keyword{Arc/Info Export} Arc/Info Import/Export files are supported by the GDB library for read operations only. These files must be uncompressed, compressed forms of these files are not supported at this time. The file is represented as a single vector segment, and assigned a georeferencing type of METRE. Currently the ARC layer is read in as polylines with the USERID as the attribute. The CNT (Centriods) and LAB (Labels) section are read in as points, and may contain attribute information. Structures read in from ARC,CNT or LAB sections will have a corresponding GROUP of 1,2 and 3 respectively. Import/Export files may be read by Works programs and the FIMPORT PACE program. See Also: FIMPORT, {..|Arc/Info Generate}Generate 2 Aries Image Format (DIPIX) @index{DIPIX (Aries) Image Format} @keyword{Aries}{DIPIX} Some Aries (DIPIX) image files (.i suffix) are supported by the GDB library. Only integer files (16/32 bit) are supported. Existing Aries files may be written to, but new files cannot be created by Works programs. See Also: LINK 2 AutoCAD DXF @index{AutoCAD DXF Format}{DXF Format} @keyword{AutoCAD DXF} AutoCAD vectors in the form of a DXF (Data Interchange File) file are supported by the GDB library for both read and write operations, with certain limitations. For read operations the only entities supported are the POINTs,LINEs, POLYLINEs. ARCs and CIRCLEs are also supported by approximating them with line segements. Unsupported entities are represented by a point. The coordinate of this point is the first X,Y coordinate pair of the unsupported entity. The DXF file will appear to contain two segments; however, the only difference in between these two segments is the manner in which the attribute for a polyline or point is determined. By selecting the first segment, the attribute is determined by the LAYER attribute of an entity. By Selecting the second segment, the attribute is based on the Z value of the first (X,Y,Z) vertex of the entity. For write operations the only entites that are written out are, LINE and POINT entities. Any ARC or CIRCLE entities that may have been read in will be written out has a series of approximating line segments. AutoCAD DXF files may be created by Works programs as well as FEXPORT. The PACE programs VECREAD and VECWRIT may also be used to import and export DXF vector data. See Also: {WORKS|Data File|File Creat}Works Create File, VECREAD, VECWRIT, FIMPORT, FEXPORT 2 CCOGIF @index{CCOGIF} @keyword{CCOGIF} The GDB library supports the CCOGIF 2.3 vector format. This format was produced by the Canadian Council on Geomatics as a standard file exchange format for digital spatial data. Only read access to CCOGIF format is available. No attributes are imported with CCOGIF vectors, and the ``area'' structure is ignored. Projection information is extracted from the CCOGIF file; however, only the Transverse Mercator (TM) projection has been tested. All others are suspect. See Also: FIMPORT 2 DEM (USGS Digital Elevation Model) @keyword{USGS File Formats}{DEM (USGS)} USGS 7.5 minute ascii DEM files are supported for reading by the GDB library. USGS DEM files contain one 16 bit channel of elevation data, and no auxiliary data. The UTM georeferencing information for the elevation data is also loaded from the DEM file. The Works programs currently do not support writing to an existing USGS DEM file, or creating new ones. By definition USGS DEM files are supposed to be based on the NAD 27 (E0) datum; however, PCI has seen some that where based on the NAD 83 datum. However, the GDB library cannot detect this, and will always report DEM files as being E0 (NAD27). The PACE tasks DEMREAD and DEMWRIT may also be used to read and write USGS DEM files. See Also: DEMREAD, DEMWRIT, FIMPORT 2 DLG (USGS Digital Line Graph) @keyword{USGS File Formats}{DLG}{Digital Line Graphs} USGS DLG (Digital Line Graphs) are supported for reading and writing by the GDB Library. The full topology of a DLG file is not retained during a read operation. Any Area information present in a DLG file will not be retained. In addition only the first attribute code of a line will be retained; all others will be skipped. DLG files written out by this program are equivalent to DLG level 2 files. When DLG files are written out, a node list is generated, and node to line as well as line to node linkages are generated. Since the full topology of the file is not retained, the left and right area fields of a Line Record will be initialized with a -1. USGS DLG files may be created by Works programs. The DLGREAD and DLGWRIT programs may also be used to import and export DLG format vector data. See Also: {WORKS|Data File|File Creat}Create File, DLGREAD, DLGWRIT, FIMPORT 2 DOQ (USGS Digital Orthophoto Quadrangle) @keyword{USGS File Formats}{Digital Orthophoto Quadrangle} USGS digital orthophotos are supported by the GDB library for read only. Digital orthophotos with embedded DEM information are not supported. Georeferencing information (always UTM) is extracted from DOQ files, but no auxiliary information is accessed. Existing DOQ files can be written to, but new files may not be created. The PACE program LINK may also be used to access DOQ image data. See Also: LINK, FIMPORT 2 DTED @keyword{DTED} The DMA's (Defense Mapping Agency) DTED (Digital Terrain Elevation Data) format is supported by the GDB library for reading and writing. Note that writing is only supported for existing DTED files and there are no provisions for creating a new DTED file. The GDB layer supports the CD-ROM DTED format. Under the specification, these files have an extension .dt1. They contain a user header label, data set identification record, accuracy description record, and the digital elevation information. The CD-ROM DTED format also implies a hierarchical arrangement of files based on georeferencing. The GDB layer does not understand this hierarchy and only knows how to read a single .dt1 file. A DTED file covers a 1 degree by 1 degree area but its resolution varies depending on which zone the file covers as well as what level the DTED file is. DTED files contain one 16 bit channel of elevation data and no auxiliary data. The UTM georeferencing information for the elevation data is also loaded from the DTED file. DTED data is based on the WGS84 (E012) datum. The Works programs currently support writing to an existing DTED file, but not creating new ones. The PACE task MIDTED can be used to read DTED files from tape into a PCI .pix database. See Also: MIDTED, FIMPORT 2 EOSAT CD-ROM @keyword{EOSAT Fast Format}{CDROM} EOSAT Fast Format is a tape format that has been extended to use as a CDROM distribution format. GDB library support has been added for this format, at least as distributed by EOSAT, RadarSat and Indian Remote Sensing Center. The directory and naming conventions for EOSAT Fast Format CDROMs may vary; however, the GDB library is only able to understand two file naming conventions. It may be possible to read EOSAT Fast Format CDROMs from other sources if the files are renamed to match one of the following conventions. - RadarSat CDROMs typically name the files as follows. /cdrom/SCENE01/VOLD_01.DAT <--- Select this file. /cdrom/SCENE01/BAND_01.DAT /cdrom/SCENE01/BAND_02.DAT /cdrom/SCENE01/BAND_03.DAT - EOSAT and Indian CDROMs typically name the files as follows. /cdrom/SAMPLES/LISS1/HEADER.DAT <--- Select this file /cdrom/SAMPLES/LISS1/BAND1.DAT /cdrom/SAMPLES/LISS1/BAND2.DAT /cdrom/SAMPLES/LISS1/BAND3.DAT Georeferencing information may extracted for some precision geocoded products; however, this has not been well tested. There is currently no support for generating EOSAT Fast Format datasets with EASI/PACE. See Also: LINK, FIMPORT, MIEOSAT 2 Erdas .GIS and .LAN @keyword{Erdas}{GIS}{LAN} Erdas version 7.4 .GIS and .LAN image files are supported by the GDB library. In fact some files earlier than version 7.4 are also supported, but the new version 8.0 files are not supported to the best of PCI's knowledge. Erdas files can be 8 bit, or 16 bit unsigned. If georeferencing information is present it will be read along with the data. It is also possible to create new Erdas files in Works programs using the ``New'' menu selection, and to write data to any Erdas file. Only the .GIS or .LAN files are read by the GDB library. None of the auxiliary or trailer files are read or generated. The PACE programs FIMPORT, FEXPORT, ERDASWR, ERDASRD and ERDASHD may also be used to operate on Erdas files. The program ERDASWR, ERDASRD and ERDASHD are not based on the GDB library and are not considered to be as reliable as FIMPORT and FEXPORT. See Also: {WORKS|Data File|File Creat|erdas}Works Create Panel, ERDASWR, ERDASRD, ERDASHD, FEXPORT, LINK, FIMPORT 2 GRASS @keyword{GRASS} GRASS dig (vector) files as well as cell (raster) files are supported by the GDB library for read and write operations. GRASS filenames may be specified in one of two ways. If there is a .grassrc file in the user's home directory, a simple filename may be given. The file will then be placed in the correct layer for the file. If the .grassrc is not present, the user must specify a path along with the filename. For vector files specified without a full path name and a .grassrc present, the dig (binary) version of the vector file will be read or written to before any ascii file. To use an ascii vector file, a path name which includes a dig_ascii directory must be specified. The dig_plus file is not modified when a binary file is written to. The user will have to use the grass program v.support to update the dig_plus file. When GRASS vectors are loaded, both Line and Area arcs are read in as polylines. The dig_att file is also read and processed. Each line attribute is associated with its unique line arc. Area attributes are read in as vector points with an attribute. Area arcs will have an assigned attribute of 0. No attempt is made to assign area attributes to their particular AREA arcs. When GRASS files are written, those lines read in as line arcs or area arcs are written out as lines or arcs respectively. Added lines are treated as line arcs. Added points will be written out as degenerate line arcs. Points that were read in as AREA attributes will not be written. These points will be written out only to the dig_att file. The non-zero attribute of lines will be written out to the dig_att file. The coordinate associated with the attribute will be the midpoint between the first two vertices in the arc. ((P1+P2)/2) Any attributes read in as AREA attributes will be output unchanged to the dig_att file. The LINK PACE program can also be used to access uncompressed GRASS raster layers. FIMPORT, FEXPORT and ImageWorks can be used to import and export GRASS layers. See Also: {WORKS|Data File|File Creat|Grass}Works Create Panel, LINK, FIMPORT, FEXPORT 2 HDF (Hierarchical Data Format) @keyword{HDF}{Hierarchical Data Format}{NCSA}{PathFinder} The GDB library supports various types of .HDF raster files. In particular simple eight bit raster (RI8), and Scientific Data Set (SDS) files should be readable. RI8 files may be run length encoded, while only uncompressed SDS files are supported. Currently no auxiliary data or georeferencing information is extracted from HDF files. RI8 files consist of 8 bit run length encode, or uncompressed imagery. SDS files may contain 8 bit, 16 bit, or floating point image channels, though floating point channels have not been tested. NASA generated PAL data has been tested and found to work fine. The Vset extensions to HDF files are not supported. The HDF format was developed by the National Center for Supercomputing Applications (NCSA), which maintains a library for accessing HDF files, and various applications for displaying and operating on HDF files. All PCIDSK support datatypes may be exported to HDF format files using the FEXPORT PACE program, though exporting more than one data type in a single HDF file is not currently supported. HDF files may have associated georeferencing information stored in an .aux file, and FEXPORT will export georeferencing in an .aux file. See Also: LINK, FIMPORT, FEXPORT 2 HIDISK (HI-VIEW image format) @index{HIDISK} @keyword{HIDISK}{HI-VIEW} The HIDISK image format used by the Horler Information Inc. HI-VIEW software (Version 111) is supported by the GDB library for reading. Writing in this format has not been implemented. 8-bit unsigned, 16-bit signed, 16-bit unsigned and 32-bit real data will be read. (32-bit signed integer data is not supported.) See Also: LINK, FIMPORT 2 Image Display Handler On Unix systems it should be possible to access the display (ImageWorks or the handler) as if it were a file, via the GDB library. Possible filenames that would refer to the display are ``VD00'', ``VD0:'', ``VD1:'', ``VD2:'', or ``VD3:''. It is possible to access the image planes of the display as channels, and graphic planes as bitmaps and vector layers as vector segments. As well the LUTs and PCTs are accessible. The overall georeferencing (ala Set Map Area) is also accessible. Note that the old handler does not support georeferencing or vector layers. See Also: FIMPORT, CDLC, IIIC, {IWORKS}ImageWorks 2 Intergraph Raster Files @keyword{Intergraph Raster Files}{Continuous Tone Files}{COT Files}{CFL Files} The GDB library supports some variants of the Intergraph Raster format. No auxiliary or georeferencing information is supported for Intergraph Raster format files. Intergraph raster files may have a variety of extensions including .rgb, .cot and .cfl. The supported sub-formats are grey scale continuous tone (type 2), compressed RGB (type 27), and uncompressed RGB (type 28), although type 28 has never been tested. Continuous Tone files cannot be created with Works programs, but the imagery on an existing file can be updated if it is not of type 27. Also the PACE LINK program can be used to access Intergraph Raster data in type 2 and type 28 files. See Also: LINK, FIMPORT 2 Joint Photographic Experts Group (JPEG) files @keyword{JPEG} The GDB library supports single scan JPEG files that contain 8 bit grey scale or 24 bit colour images. GDB will read both YCC and the less common RGB colour space JPEG files, but will always write the YCC variant. When writing a JPEG file, all three channels must be written at the same time. When reading a JPEG file, it is vastly more efficent to read it in a pixel interleaved fashion, but reading in a band interleaved fashion is supported (on average it will take three times longer). The GDB JPEG support is based on the Independant JPEG Group's (IJG) version 4 code. A suite of public domain Unix tools for dealing with JPEG files is available by anonymous ftp from unix.hensa.ac.uk in the directory /pub/uunet/graphics/jpeg as jpegsrc.v4.tar.Z. See Also: FIMPORT, JPEGRD, JPEGWR 2 LAS Image Format @keyword{LAS Image Format} The LAS Image File Format is supported for read access by the GDB library. The LAS format is used to stored various types of geocoded image data. Typically a LAS image will consist of several related files. The two used by the GDB library are the .ddr and .img files. The .ddr files contains header information and geocoding, while the .img file contains the actual imagery. Either file may be used to refer the the LAS image, but both must exist in the same directory with the same base name. The GDB library reading and updating imagery on LAS files. As well, in some circumstances it is possible to read georeferencing information. In theory any of the USGS style projections may work, though in practice only UTM has been tested. There is currently no option to export imagery in LAS format. See Also: LINK, FIMPORT 2 Laser-Scan @keyword{Laser-Scan} Five of the seven types of Laser-Scan image files are supported by the GDB library. Functions exist to read, update and create Laser Scan files, though image update of compressed files is not possible. There is no support for georeferencing, or any auxiliary data other than pseudo-colour tables (PCTs) with Laser-Scan files. The supported Laser-Scan file types are: - 2: Greyscale (uncompressed, LINKable) - 3: PseudoColoured Image (compressed) - 4: RGB (24 bit uncompressed, LINKable) - 5: Bitmap (uncompressed) - 7: PseudoColoured Image (uncompressed, LINKable) The RLE and PackBits compressed bitmap file types (1 and 6) are not supported at this time. The type 3 compressed pseudocoloured image files use a simple run length encoding scheme. The image channel may not be updated after the initial creation. The pseudo-colour table (PCT) may be stored in a related .PAL file, in which case it is available to read. If the .PAL file does not exist the pseudo-colours are lost. See Also: {WORKS|Data File|file creat|laser}Works Create Panel, LINK, FIMPORT, LSCANWR, FEXPORT 2 LGSOWG CD-ROM @keyword{LGSOWG}{Spot Image}{ESA}{CDROM} LGSOWG is a magnetic tape format that can be extended to be used as a CD-ROM distribution format. A GDB library support has been added for the base format. The directory structure and naming conventions may vary. Examples produced by various agencies are as follows. In each case, you would select the imagery file. - Spot Image CD-ROMs typically have a directory structure as follows. /cdrom/SCENE01/VOLD_01.DAT /cdrom/SCENE01/LEAD_01.DAT /cdrom/SCENE01/IMAG_01.DAT <--- Select this file /cdrom/SCENE01/TRAI_01.DAT /cdrom/SCENE01/NULL_01.DAT ... - ESA CD-ROMS may have the following structure. The following example is organized in a BSQ (Band Sequential) format for one scene. Each band of the scene is in a separate file, so you would select and then display the imagery, for as many bands as you want. ... /cdrom/scene1/lea_01.001 /cdrom/scene1/dat_01.001 <--- Select this file and load imagery /cdrom/scene1/tra_01.001 /cdrom/scene1/lea_02.001 /cdrom/scene1/dat_02.001 <--- Select this file and load imagery /cdrom/scene1/tra_02.001 ... - Radarsat CD-ROMS may have the following structure. /cdrom/lgsowg/vold_01.dat /cdrom/lgsowg/lead_01.dat /cdrom/lgsowg/imag_01.dat <--- Select this file /cdrom/lgsowg/trai_01.dat /cdrom/lgsowg/null_01.dat - CCRS CD-ROMS may have the following structure. /cdrom/me0072/me0072.vol /cdrom/me0072/me0072.ldr /cdrom/me0072/me0072.img <--- Select this file /cdrom/me0072/me0072.trl /cdrom/me0072/me0072.nul Currently none of the header or trailer files are utilized. Only reading and updating of the image data is supported. It is not possible to create these files, nor is there any auxiliary information. Also note that writing is only supported if the dataset is copied to disk from the CDROM. LGSOWG magnetic tapes can be read with the PACE program MIL, and LGSOWG CD-ROMs can be accessed via the PACE program LINK. See Also: MIL, LINK, FIMPORT 2 MicroStation Design Files (DGN) MicroStation DGN files are supported by the GDB library for read access only. Both Raster and Vector data may be read from DGN files. Three formats of Raster Imagery are supported: Compressed Binary, Binary, and Byte. The georeferencing system for raster imagery is PIXEL. The supported vector entities are LINEs (3), LINESTRINGs (4), SHAPEs (6), and CURVEs (11). Since a curve (with n points) is defined by interpolating through all points, except for the first and last two, curves are approximated as a polyline defined by the interior (n-4) points. Unsupported entities are ignored during the read operation. For COMPLEX elements, the individual elements which comprise a complex element are read in as separate structures, not as one complete structure. The georeferencing system for the vectors is PIXEL. See Also: LINK, FIMPORT 2 NITF @keyword{NITF} A subset of the NITF (National Imagery Transmission Format) used by the the U.S. Government is supported by the GDB library for reading and writing. Imagery that may processed will be single bands of 8-bit unsigned data that has no compression. Lookup or pseudocolour tables are not supported to date. NITF files where the Image Coordinate System is G (Geodetic) or C (Geocentric) will have 'LONG/LAT' Georeferencing when read by FIMPORT. All other Georeferencing is output as None or imported as 'PIXEL'. (UTM Georeferencing has not been implemented to date.) NITF files can be generated with FEXPORT. See Also: FIMPORT, FEXPORT 2 PCIDSK @keyword{PCIDSK} PCIDSK is fully supported by the GDB library. It is the only file format which currently allows ``adding'' segments, and one of the few for which data description fields are actually extracted and saved to the file. The channel and segment description fields which appear in the Load and Save panels are related to the most current history records in the PCIDSK file. When image or segment data is written to the file, a new history record is written with the current description and the name of the Works program. At the current time there are no facilities in the Works programs for performing database maintenance functions on a PCIDSK database such as deleting segments, deleting or adding channels, or modifying the georeferencing information. EASI/PACE programs are required to do these functions. See Also: {WORKS|Data File|file creat|pci}Works Create Panel, CIM, PCIMOD, III 2 PPM @keyword{PPM}{PGM}{PBM}{pbmplus} Raw PPM, PGM and PBM files are simple raster formats supported by the GDB library. ASCII formatted PPM, PGM and PBM files are not supported. These files are an interchange format used by the popular `pbmplus' file interchange utilities. - PPM: RGB format, only 24 bit supported. - PGM: Greyscale, only 8 bit supported. - PBM: Bitmap, all supported. PPM, PGM and PBM files have no auxilary information such as georeferencing, LUTs, or PCTs; however, georeferencing will be exported in an .aux file. These formats are supported for read, write and update. The PPM and PGM files can be accessed with the LINK program. See Also: LINK, FIMPORT, FEXPORT 2 Raw Image Format @keyword{Raw image format}{User described image files} The GDB library has a facility for reading and writing imagery in user described raw files. The files are described to the GDB layer by a complex naming convention. This is not intended for interactive use, but may be important in some batch or scripted environments. The naming convention for raw files is: RAW:::filename xsize ysize bands [offset {8U/16U/16S/32R} {PIXEL/LINE/BAND}] [*CHANNEL chan_num {8U/16U/16S/32R} offset pixel_off line_off [swapped/unswapped]]* The absolute simplest file description would describe a band sequential file of eight bit data that is tightly packed with no header. For example the following would describe the file ``raw.dat'' as being three bands, 512 pixels by 512 lines. RAW:::raw.dat 512 512 3 A slightly more complex form can be used to define any file that could be read with IMAGERD. This adds the offset to the first byte of imagery, the data type and the interleaving mode. The following description defines the same file as the previous one but it explicitly states that the offset to the first byte of imagery is zero, and the data is eight bit unsigned and that it is band interleaved. RAW:::raw.dat 512 512 3 0 8U BAND Many file organization can not be described this way. For instance files with more than one data type, or files with spaces between bands or byte swapped multi-byte data. In these cases it is possible to describe the layout of each channel. The following description described the same raw.dat as in the previous two descriptions. For each channel a data type, image offset and swappedness is provided. The first offset is the offset to the first byte of data, but is specific to the channel, so we see that channel two data starts at byte 262144 in the file. The second offset is the offset from one pixel of data on the same scanline to the next pixel of data on the same scanline. The third offset is the offset from the beginning of one scanline to the beginning of the next. The swap flag indicates whether the data is in little endian order or not. Little endian byte order has the least significant byte of the word first, and is found on Intel and VAX machines. This is considered `swapped'. Big endian machines such as the Motorola and sun are considered `unswapped'. The default is the native byte order of the current machine. RAW:::raw.dat 512 512 3 *Channel 1 8U 0 1 512 unswapped *Channel 2 8U 262144 1 512 unswapped *Channel 3 8U 524288 1 512 unswapped A more interesting example might be a 300x400 one band file with little endian 16bit unsigned data starting after a one block (512byte header). RAW:::testi2.dat 300 400 1 *Channel 1 16U 512 2 1024 swapped User defined raw files are supported for reading and writing. Georeferencing (or Projection) information will be written to an auxiliary file which has the same name as the data file but with the extension ``.aux''. See Also: IMAGERD, PCIADD2, FEXPORT 2 Siemens SICAD (.SQD) @keyword{Siemens SICAD SQD} The GDB library supports Siemens SICAD .SQD vector files for import and export. Only the line (ETYP=LY) and point (ETYP=PG1) structures are supported on import, and generated on export. All other structures are silently ignored. There are a variety of attributes that could be extracted with SQD vector data; however, there is only one Attribute field per structure in the PCIDSK vector segment. Currently the GDB library extracts the value of the SQD ENUM field as the attribute, and ignores the STU, EB, NAM, PKZ and PNR fields. On export all fields expect the ENUM are initialized to a legal value. Due to the loss of much of the attribute and structural information it is generally not practical to import SQD files into EASI/PACE and then export them to SICAD again after performing some operations. SICAD georeferencing information is lost when importing SICAD files, and a units string of METRE is assumed. See Also: FIMPORT, FEXPORT 2 SPANS Vector Archive @keyword{Tydac SPANS VEC/VEH} @index{SPANS Vector Archive format} The GDB library supports the SPANS Archive format for both read and write operations. The SPANS archive format consists of two files, which have a common basename and .VEC and .VEH extensions. The VEC file contains the actual data, whereas the VEH is the header file and describes the contents of the VEC file. Both the ARCS and POINTS data types will always be read. The NODES section is always ignored. If the AREAS section is defined in terms of ARCS then this section will be ignored, if the AREAS section is defined in terms of vertices then the AREAS section will be read. Only an ARCS and POINTS data section will be written to the VEC file, the type of vector file which is written out is in ARC format, without topology, and composed of unclean lines. SPANS Vector files may not be modified. Due to the loss of information such as topology it is generally not practical to import VEC/VEH files into EASI/PACE and then export them again. See Also: FEXPORT, FIMPORT, VECREAD, VECWRIT 2 SPANS Raster @keyword{Tydac SPANS RNH RNL} @index{SPANS Raster}{RNH}{RNL} The SPANS Raster format is the Tydac SPANS raster interchange format. This format can store various raster data types including eight bit unsigned, sixteen bit signed and sixteen bit unsigned. The GDB library support SPANS Raster format for import and export. SPANS Raster header files always have the extension .RNH. Of the many possible datatypes of SPANS Raster files, only 8U, 16U and 16S are supported. All others will are unreadable. As well some SPANS Raster files may be run length encoded, or ASCII encoded. These are also not supported. SPANS Raster files are supported by the LINK program. Projection and georeferencing information is supported on import and export for most projection and ellipsoid types; however, there are cases that do not translate between systems. SPANS Raster files do not contain any other auxilary data items. SPANS colour table files are not supported at this time. See Also: LINK, FEXPORT, FIMPORT 2 SPOTView GIS-GEOSPOT @keyword{Spot Image}{GEOSPOT} The SPOTView GIS-GEOSPOT image format is a GIS ready image product distribution format used by Spot Image. The GDB library supports the SPOTView 4.0 format, now being distributed by some Spot Image distributers. The software has also been successfully used with some SPOTView 1.5 format datasets. The SPOTView distribution format includes a number of auxilary files organized in two levels of directories. In the each subdirectory should be one or more files ending in the extention .BIL and .HDR. The .HDR file contains georeferencing and structural information while the .BIL file contains just image data. The user may name either file to access the dataset with the GDB library. Georeferencing information is handled for some projections; however, due to limitations in the available documentation some Spot Image supported projections are not currently full supported. There is no support for exporting in SPOTView format. See Also: FIMPORT 2 Sun Raster @keyword{Sun Raster} Pseudocoloured, greyscale, and RGB Sun Raster files are supported by the GDB library. This is a format generated by several Sun utilities as well as many popular scanners. Sun Raster files will have one or three image channels, and may contain a PCT, or three LUTs depending on the configuration. Sun Raster files do not contain any georeferencing information, nor do they contain any fields describing the data. Sun Raster files can be created using the ``New'' menu selection in Works programs. See Also: {WORKS|Data File|file creat|sun}Works Create Panel, LINK, FIMPORT, FEXPORT 2 TARGA @keyword{Targa Raster} Two forms of Targa raster files are currently supported currently these forms are uncompressed True-Color and Black & White formats. Color-mapped images and any run-length encoded images are not supported at this time. For Targa True-Color files 16,24, and 32 bit images are all supported. A True-Color file will appear as a three channel file, each file will contain either the Red,Green or Blue component of the color image. Black & White Targa files will appear as a file with a single channel. The GDB layer also supports the output of Targa files. Again only True-Color and Black & White images are supported for write operations. The GDB layer will only output True-Color 24-bit files, which require as input three 8-bit channels. If a single channel is to be written ou the output will be a black and white Targa file. See Also: {WORKS|Data File|file creat|sun}Works Create Panel, LINK, FIMPORT, FEXPORT 2 TIFF @keyword{TIFF} Several common forms of TIFF files are supported by the GDB library. In particular, it should be possible to read TIFF B (Bitmap), TIFF R (RGB), TIFF P (Palette), and TIFF G (Greyscale). Files with none, LZW, or PackBits compression are supported, as well as some other compression schemes. TIFF G files contain one channel of imagery. TIFF B files contain a single bitmap. TIFF P files contain a single channel of imagery and a pseudocolour segment. To properly view the image, it is necessary to load both imagery and segment, and place the display in pseudocolour mode. TIFF R files contain three image channels (RGB). TIFF files do not support LUTs or georeferencing. No descriptive data is extracted from the TIFF file, nor is any written back. It is possible to create new uncompressed TIFF files with the TIFF Create Panel in Works programs; however, at this time the only way to create compressed TIFF files is with the FEXPORT PACE program. Any uncompressed TIFF file that can be read, can also be written to; however, this is not true of compressed TIFF files which are read only. @ifhlp The Tagged Image File Format (TIFF) was designed to be an extendible, all-purpose standard for image interchange. A TIFF file consists of an image, with a list of information tags describing the image. A variety of image orderings are possible using TIFF files, as well as various types of compression. The TIFF format is extendible, as new information tags can be added at will, and TIFF file readers are required to ignore tags they do not understand. Because it is realistically impossible for a TIFF reader to read all possible TIFF format files, a small number of TIFF subset classifications have been developed. Requirements for reading and writing these classified files have also been developed. Relevant classes are TIFF B (Bilevel or Bitmap), TIFF G (Grey level), TIFF P (Palette or Pseudo-Colour) and TIFF R (RGB) all of which can be read with either TIFFRDB (TIFF B) or TIFFRDI (TIFF G/P/R). TIFFWR is able to generate TIFF B, TIFF G or TIFF R files, but not TIFF P files (files containing a pseudocolour table). The supported classes have a variety of possible compression schemes, of which LZW, PackBits, CCITT 3 Fax and CCITT 4 Fax are known to work. PCI's TIFF support does not include 16 bit data, or any other datasizes besides one bit (bitmap) and 8 bit. PCI would like to thank Sam Leffler and SGI for providing the ``libtiff'' TIFF library, on which all of PCI's TIFF support is based. A libtiff based suite of public domain Unix tools for dealing with TIFF files is available by anonymous ftp from sgi.com on the Internet. These tools include functions to compress and uncompress TIFF files using most known TIFF compression schemes. Additional information on the TIFF format was extracted from the book ``Practical Image Processing in C'' by Craig A. Lindley from Wiley Professional Computing. @end See Also: {WORKS|Data File|File Creat|tiff}Works Create Panel, FIMPORT, LINK, FEXPORT 2 UK National Transfer Format (.NTF) @keyword{NTF}{Ordnance Survey} The GDB library supports most NTF 2.0 format files provided by the Ordnance Survey in the United Kingdom for import. All Ordnance Survey data provided in 1994 and on will be in NTF 2.0 format. It is unlikely that the older formats will work. The Land-Line, Oscar, 1:625000 Topographic, 1:250000 Topographic, 1:50000 Contour and 1:50000 DTM are believed to be supported, though it is possible that some structures are lost with some of these formats. Boundary-Line files are known not to work. All of these formats are vector with the exception of the DTM files which are raster height fields constructed from contour information. There are a variety of attributes that could be extracted with vector data; however, there is only one Attribute field per structure in the PCIDSK vector segment. To get around this limitation, NTF files are represented as having two segments. Each contains the same vectors, but with different attributes. Segment 1 of an NTF vector file will contain vectors with the feture code number as the attribute. The second segment will contain vectors with the value as the attribute. All NTF files are georeferencing in the UK's National Grid projection which is a type of Transverse Mercator. The GDB library will represent vector and raster data with the appropriate TM projection characteristics; however, the projection characteristics are: - Reference Longitude: 49.0 - Reference Latitude: 2.0 - False Easting: 400000 - False Northing: -100000 - Scale: 0.9996012717 - Ellipsoid: Airy 1830 (E009) There is no support for updating, or writing NTF files, nor can the DTM files be LINK'ed to. See Also: FIMPORT 2 UNIDSK-VMS @keyword{UNIDSK-VMS} UNIDSK-VMS image files are partially supported by the GDB library. UNIDSK-VMS is a file format used primarily by the Canada Center for Remote Sensing (CCRS) and related facilities. It is related to the original PCI UNIDSK format, which was replaced by PCIDSK several years ago. UNIDSK-VMS is supported for read and update access, but new UNIDSK-VMS files cannot be created. No georeferencing, or auxiliary information is extracted from UNIDSK-VMS files. Only 8 bit BIL, 16 bit BIL, 8 bit BSQ, and 16 bit BSQ UNIDSK-VMS files are currently supported, although only 8 bit BIL has been tested. There are no PACE programs specifically for reading or writing UNIDSK-VMS files but the LINK program does support this format. See Also: LINK 2 VICAR @keyword{VICAR}{AVIRIS} VICAR format can be read by the GDB library. VICAR format is used for AVIRIS data (Airborne Visible/Infrared Imaging Spectrometer). Writing or updating VICAR format is not supported by the GDB library. See Also: FIMPORT 2 WorldMap @keyword{WorldMap}{JEBCO} WorldMap is a image format originating in the Soviet Union. Data is distributed in the United States by JEBCO. The example files provided by JEBCO where one band, and the assumption is made that all WorldMap files are one band. WorldMap files are supported for reading and updating of imagery. It is also possible to LINK to WorldMap files. No georeferencing or other auxiliary information is supported for WorldMap files. It is not possible to create WorldMap files. WorldMap scenes consists of a number of related files, including a header file which must have the extension .rh, and the raw imagery file which must have an extension of .bsq or .bsf.w. Either of these three files may be selected to access the WorldMap image. See Also: LINK, FIMPORT 2 X Window Dump @keyword{X Window Dump} Pseudocoloured, greyscale, and RGB X Window dump files are supported by the GDB library. This is a format generated by the widely available xwd program available on many Unix workstations for capturing screen dumps. X Window Dump files will have one or three image channels, and may contain a PCT, or three LUTs depending on the configuration. X Window dump files do not contain any georeferencing information, nor do they contain any fields describing the data. X Window Dump files can be created using the ``New'' menu selection in Works programs. See Also: {WORKS|Data File|File Creat|x win}Works Create Panel, LINK, FEXPORT, FIMPORT 1 Programs Using GDB Library The following programs are intended to be able to access many, or all GDB file types, and may be considered to be generic import and export programs. See Also: LINK, FIMPORT, FEXPORT, IIIC, CDLC, {IWORKS}ImageWorks, GCPWorks