The AGI database system implementation has changed in the current version. It now exists as two subroutine libraries – one, which is unchanged from earlier versions, to handle all graphics interactions where GKS is the underlying graphics package (the AGI library) and a new library which interfaces to native PGPLOT only (the AGP library). In both these libraries the routines are split into two functional types. One set of routines deals with the manipulation of, and navigation around, the database; these routines are prefixed with AGI_. The other set of routines provides an interface between the database and the graphics package used by the application. In the AGI library these routines are prefixed AGS_ if the graphics package is SGS (SUN/85), AGP_ if the package is GKS-based PGPLOT (SUN/15) and AGD_ if the package is IDI (SUN/65). The new AGP library only interfaces to native PGPLOT (SUN/15) and so only contains those graphics routines prefixed with AGP_. The two libraries can create identical database files on disk and thus new native-PGPLOT applications can be arranged to co-exist with older applications based on GKS. Current Starlink policy is that GKS is being phased out and so all new applications should be designed to use the AGP library only.
The basic structure of the database is an object called a picture. This represents a rectangular area on the display surface and contains information about the coordinate system in use when the picture was created. Pictures are usually created in the database by one of the interface routines specific to a particular graphics package. For instance the routine AGS_SZONE will save the extent and coordinate system of the current SGS zone as a picture in the database. However pictures in the database are independent of the graphics package that created them. This means that, for example, a picture created by one application using SGS graphics can be used by another application employing PGPLOT. It is even possible, with care, to use two graphics packages, such as SGS and IDI, in one application by using AGI to mediate between them.
Although pictures are independent of a graphics package they are not independent of the graphics device to which they refer. When a picture is created it contains an implicit reference to the current device, even if nothing has been plotted on the screen or even if a graphics package has not been activated on the device. The pictures in the database are grouped into a larger unit, here called a workstation structure, that contains all the pictures on a given device, stored in the order they were created.
Pictures are given a name which gives an indication of what the plotting space contains. For effective communication between applications it is important that the picture names are standardised. It is customary for a picture containing other pictures to be referred to as a ‘FRAME’ picture, and a picture containing a plot to be referred to as a ‘DATA’ picture. A ‘BASE’ picture refers to the whole plotting space and this name should not be used for other purposes.
As well as a name a picture structure contains a one line comment field which can be used to further identify a picture in the database. The name, comment and coordinate system are mandatory components of a picture in the database, but there are some other components which are optional. The first is a reference to the data associated with a picture. This is a complete description of where the data is located, containing both the file name and the location within the file. This can be used by a later application to access the same data set without having to prompt the user again.
The second optional component is a transformation structure. The default coordinate system of a picture stored in the database is a simple orthogonal linear set that increases left to right and bottom to top. If the coordinate system of a plot on the screen does not conform to this rule then a transformation which defines the relationship can be saved in the database. For example, an application may have displayed an image and saved a transformation from pixel coordinates to right ascension and declination in the database. A later cursor application can then use the transformation to report its results in these non-linear coordinates.
The last optional component of a picture is a label. This is basically a short character string which can be used by an application to uniquely identify a picture. Unlike the other components of a picture the label contents can be changed at any time, the only restriction being that the label is unique on a given device.
If it is necessary to store additional information in a picture structure, that cannot be accommodated by any of the defined components, then a MORE component is available for this purpose. It is important to remember, however, that the structure and contents of the MORE component can only be interpreted by applications that know how to use it, and a general purpose application will ignore the MORE structure.