Site Map
 

It effectively provides the 'missing link' between software processing data structures representing real world data and the graphical output system, generally some form of Graphical Device Interface (GDI) such as Microsoft Windows.

Most conventional GDIs concentrate on providing the graphical support required. However they generally give insufficient support when it comes to handling data structures that are capable of representing real world data. For example the coastline on a map should be able to be stored and processed as map grid coordinates at a scale of 1:1. The process of converting that data to pixels on the screen or to produce a printed page should not be the responsibility of the application program.

Many commercial CAD packages exist which allow this type of real world data representation and its conversion to displayed or printed output. Some have user programming facilities, and most support some form of file exchange. However the following reasons constitute the requirement for the creation of TGS:

• Commercial CAD packages are marketed as a complete entity. They are not available as a modular subsystem that can be linked into an application program, or embedded in an item of hardware.

• No commercial CAD packages support the animation facilities provided by TGS. TGS provides automatic and fast redrawing of graphics as status information is received, with a minimum of involvement by the application program. Real time 2D and 3D animation is supported.

• No commercial CAD packages support a backward flow of information from the user operating the CAD software to the application program. For example this may be user's selection of a waypoint, or the positioning of a cursor symbol which gives its real world map grid coordinates to the application program.

• TGS provides a single, consistent interface to the application program which is invariant under operating system and GDI changes. This allows easy porting of software to different platforms, with only some internal TGS modules being changed.

TGS is defined as an eight layer model.

The application layer describes the application program itself, as well as the TGS API and TGS API translation modules.

The organization and control layer describes organization and control operations within the TGS core, as well as application specific TGS modules and symbol libraries.

The 3D graphics layer describes the storage of 3D graphic primitives, and 3D editing facilities.

The 2D graphics layer describes the storage of 2D graphic primitives, and 2D editing facilities.

The resource layer describes the resources or drawing tools used by 2D primitives to produce graphic output - pens, brushes, fonts etc.

The GDI layer describes the TGS interface to GDIs such as Windows, and import and export modules for special device and file format interfacing. This layer also describes the GDI itself.

Generally the GDI layer, device driver layer, and hardware layer are external to TGS. This would be the case for example if Windows is being used for graphical output. However in some embedded applications all layers may need to be within the scope of TGS.

The power of TGS lies in its modularity. It has been designed to cover all conceivable combinations of environments - different GDIs, different operating systems, static or dynamic linking, embedded applications in special equipment, multitasking/multiprocessor architectures etc.

TGS is composed of a library of modules. Only those modules needed to provide the required functionality need be linked into the required application. This keeps the code size to a minimum.

Return

Next Page