This chapter addresses the need for and availability of stand-alone utility programs that will assist in the deployment of a Hipparchus-based application.
Hipparchus stand-alone utilities are cross-platform ANSI C language programs that must necessarily be compiled and linked for a specific development or end-user platform. To ensure that this is understood, the utilities are distributed in source form only. Being cross-platform, they invoke no graphical user interface (GUI). Instead, they are restricted to command line programs that rely at most on the standard C/C++ stream I/O run-time facilities.
The Hipparchus Utilities call on Hipparchus Library and Hipparchus Auxiliary Library functions to perform much of their required work. Distributed in ANSI C source, portions of their code and functionality may be incorporated freely into your application.
The Hipparchus Utilities are fully described in the companion publication Hipparchus Utilities Guide.
The Hipparchus Utilities assist the Hipparchus application programmer to establish an appropriate spatial indexing Voronoi cell structure, to import or export voluminous data, to create Hipparchus binary objects as memory-mapped files, to create Hipparchus-oriented static geographic data collections and to perform miscellaneous off-line file translations such as the conversion of GPS traces to regular line sets.
The purpose of this chapter is to review the various methods of generating geographic output from your application and receiving geographic (mouse) input. In addition, we review considerations for the preparation of hard copy (plotted) output.
First, remember that all of the Hipparchus functions for geographic output and input have been provided in source form. This is so that you can more easily interface your application to the graphical environment of your choice. The majority of the sample graphical functions provided with your environment are intended for use in Win32 applications. You may choose to use other GUI options such as Windows CE or X Windows.
The h9 section of the Hipparchus Auxiliary Library provides you with generic functions to draw geographic points, lines (geodesics) and objects (point sets, line sets and regions). Other characteristics, such as color, line width, style, etc., need to be managed by your application. To expand your graphical capability, please refer to your standard sources on graphics. Your choice of graphical platform will determine the specific means to perform the following:
In the h9 functions, these operations are invoked via macros (for screen display) that are defined in the header file hippgsys.h. Their hard copy counterparts are implemented as functions in the h0_Hpgl... family of functions. If either of these macro/function groups do not match your environment, you should substitute more appropriate ones and recompile. For examples of the usage of these basic operations, please refer to the source for the GALILEO and/or GEORAMA sample applications.
Output presented on a screen differs from hard copy output formats in one critical dimension - time! The importance of providing sub-second response for human interaction is well understood. This means that you must make every effort to provide rapid delivery of information to the display.
For most textual material, you can deliver a whole screen of information (say 25 lines of 80 characters each, about 2000 characters) in a relatively short time. The design and processing considerations to achieve this are usually straightforward.
For a graphical presentation, however, you may conceivably need to process 10,000 records to extract and draw 10,000 line segments on the display. The differences are huge, without any consideration of the processing involved. These differences (i.e., potentially several orders of magnitude in data volumes) demand a thoughtful approach if you are to achieve the needed speed and efficiencies.
In particular, you will need to pay special attention to the following:
Hipparchus has been designed to help optimize the performance of your geographic presentations.
First, Hipparchus can provide extremely efficient indexing to your externally stored data. This means that when your user opens a window on a particular view of her/his data, Hipparchus can help you find that data faster than ever before, all other things being equal.
Second, in directing your search for the data, Hipparchus can select only that output information which is required for the window. In other words, Hipparchus is smart enough to tell you what to ask for from your database (i.e., only that data for the presentation window that fits inside the window, or along its border). There is not much use in retrieving more data for presentation than is absolutely necessary. But, having retrieved the interior and border data, you will normally use your graphics package (GUI) to "clip" any points, lines or areas that might be just outside the window frame.
Third, Hipparchus provides very efficient projection algorithms in mapping geographic features from the ellipsoid to the plane of the display. More is said later about your various projection options. Our point here is that these algorithms are very fast and take special advantage of the internal storage formats used extensively in Hipparchus to represent geographic objects.
These three features of Hipparchus combine to provide a very powerful engine for generating geographic presentations. This will become even more apparent to your users when they change the scale or move the viewpoint of a window. Redraw times will be the fastest that they have likely ever seen.
With other systems, the designers have usually had to trade off inefficient data retrieval and projection calculations for acceptable application response times. To effect this trade-off, window scales and viewpoints are often restricted to pre-set options so that a whole area of interest can be retrieved and projected on the first request. Subsequent requests merely move the window around in this larger area, without re-projecting. Although such secondary browsing techniques may have acceptable response times, they generally have undesirable effects on RAM usage and presentation resolution. Usually, just one Earth tangency point has been chosen for the projection, so as the user moves away from this point, the inherent planar distortion of the display increases.
With Hipparchus, however, you will be able to let your client roam freely, without prior restriction as to projection, scale or viewpoint. Since data can be selectively retrieved at high speed every time your client respecifies the window, you will seldom need to provide intermediate buffering. And since its geographic attributes can be efficiently re-projected with every change of the window, the presentation will always be at the maximum accuracy obtainable from your client's database and display equipment. The Earth tangency point for the display will always be centered in the window and the pixel scaling factor chosen so that the maximum resolution is obtained for that window.
As well as speeding the output of geographic information, Hipparchus can also be used as a powerful ally in its input.
If your application environment will include a graphics pointing device (for example, a mouse), then you will be able to use the "un-mapping" functions of the Hipparchus Library. These functions let you relate pixel coordinates read from your mouse driver (or GUI) to positions and objects on the ellipsoidal Earth.
For example, you might ask your user to "point and click" at a particular spot on the ground for which she/he needs more information. By un-mapping the window coordinates to ground coordinates, you can select a new window scale and tangency point, and then re-select and re-project the information for the next window display. For an example of this type of operation, see GALILEO's Reframe command.
In another example, you might ask your user to use the mouse to trace out the boundary of an area of interest. You would then unmap the whole sequence of window coordinates making up the area, construct an internal region object, intersect this with other data objects and give her/him back the resulting selection of data. For examples of these operations, see again the sample application GALILEO and its Interact.scr script.
You will find many examples of mouse input possibilities in the sample programs. For more information, see Appendix B - Galileo and Georama.
In constructing your various geographic displays, you might want to view the surface of the Earth in three quite different ways:
Hipparchus allows you to choose any one of these three views using the following cartographic projections:
First, the Hipparchus Library provides functions to map positions from the ellipsoid to positions on the plane using any of these seven projections. For each mapping function provided, there is a corresponding un-map function that projects from the plane back onto the ellipsoid.
To support general geographic display needs, we have provided higher level Hipparchus Auxiliary Library functions to enable the rapid development of geographic displays. These are available in source form so that you can see how it's done.
You may require some guidance in selecting an appropriate projection and scale for your displays.
The stereographic projection (stereo) is usually used to display maps that depict areas of the Earth not greater than a continent. Despite its name, it does not convey a sense of the third dimension. Here is an example of a stereographic projection.
It's most striking features are the following:
The stereographic projection is an excellent one for depiction of smaller areas anywhere on the surface of the Earth. The tangency point can be anywhere, even centered on one of the poles. The stereographic projection is developed as though the Earth were hollow and rays of light defining the features were emanating from a point on the other side of the Earth from the tangency point, that is to say, from the point antipodal to the tangency point.
The gnomonic projection (gnomonic) is often used for the depiction of small objects. Like the stereographic projection, its tangency point can be anywhere. The gnomonic projection is developed as though the Earth were hollow and rays of light defining the features were emanating from the center of the Earth.
For small areas, the gnomonic projection has attributes very similar to the stereographic projection. Since it is far faster to generate, it is the projection of choice for the depiction of small objects at large scale.
The Lambert-like projection (conical is a display option used to approximate the Lambert-1 or Lambert-2 projections used mainly in the aeronautical and meteorological fields.
The world-wide Mercator projection (wwmerc) is the familiar projection in which all of the world can be depicted on one display. Figure 17 is an example of a Mercator projection.
Of course, the Mercator projection suffers badly from distortion near the poles. However, it has compensating advantages. These are:
Mercator projections usually depict the whole world centered at the prime meridian (which passes through London). With the Hipparchus Library, you can center the projection on any meridian and depict smaller areas than the entire Earth. By definition, the Mercator projection always has a tangency point on the Equator. The Mercator projection appears somewhat as though it might be developed by projecting rays from the center of a hollow Earth onto a cylindrical screen wrapped around it, touching at the Equator. The Mercator projection however is not actually a projection in the geometric sense; it is defined in a mathematical sense only.
The world-wide Miller-like projection (wwview) also depicts the whole world centered at a meridian of your choice. Unlike the world-wide Mercator projection, the world-wide Miller-like projection caries the view to the poles. This projection is particularly useful in depicting the paths of polar orbiting satellites.
The orthographic projection (ortho) is sometimes called a "3D" projection in that it depicts the Earth as seen from space. This projection is developed as though the observer was infinitely far away, but its scale can be set freely so that it occupies more or less of the display. You can also set the tangency point freely, so that your user can look at the Earth from directly above any point, even one of the poles. Figure 16 is an example of an orthographic projection.
To support your geographic display development, we have included a number of generic geographic display functions that can complement your own graphics support facilities.
The h9 section of the Hipparchus Auxiliary Library provides projection functions for the following geographic features:
The h9 section of the Hipparchus Auxiliary Library also provides a useful set of map generation functions which include:
With this set of functions, you can display virtually any combination of points, lines and regions in a variety of formats. The stereographic, gnomonic, Lambert-like, Mercator, Miller-like and orthographic projection options permit you to generate geographic displays in forms familiar to your clients.
The h0 section provides functions for generating specific coastline displays using any of the seven projections: stereographic, gnomonic, conical, Mercator, word-wide Mercator, worldwide Miller-like or orthographic. These functions use world coastlines data packaged exclusively for this purpose. Using these coastlines for visual orientation can make the display of your other data more effective. For more about the world coastlines data, see Appendix B - Galileo and Georama.
To present your output, either on a display or in hard copy, you need to select an appropriate scale. Scale is defined as the ratio of a window distance to an equivalent distance on the ground. For your display, you need to know its size and decide what portion of it you want to use for a window and for the object to be displayed. You may want to reserve a portion of the display or window for error messages or other textual data.
Typically, a color display screen will be 10 inches wide and 7.5 inches high (having an aspect ratio of 4:3). In metric or SI units, this will be 0.254 meters by 0.184 meters (25cm x 18cm). These are typical numbers. Refer to the technical reference manual for your specific display monitor for the exact numbers for your display, or better yet, measure them yourself!
In mapping, scale is represented as a ratio, for example 1:50,000. In this example, every 1 millimeter (mm) on the map represents 50,000 millimeters (50 meters) on the ground. The ratio a:b gets a bit trickier when different units are used. For example, where one inch on the map is used to represent one mile on the ground, the scale will be 1:63,360 (figure it out). In general, there's less chance of error when you calculate scale using metric units.
If you wanted to display an image of the entire Earth on your display, you would need to know the size of the Earth as well as the size of the display area. The Earth's radius is about 6,370,000 meters. Double that for its diameter. To see it displayed with some room to spare around it, you might decide to scale it such that it would be 15 cm in diameter on the display. To set the scale, you would merely divide the Earth's real-life diameter (6,370,000 meters times 2) by the display diameter (0.15 meters) to get the scale (1:84,900,000). You would normally present the inverse of this scale to the Hipparchus functions as an exponential number, in this case 84.9e6.
You normally use the function h9_InitWindow to set the scale of the window for subsequent presentation of objects.
You should always consider importing topographical data for use in providing visual references for your graphic presentations. For example, you may have access to a file of data on roads, rivers, railways, survey lines, etc. It is a simple matter to create an object from this data and display it as needed by your application. Even if such objects are never brought directly into your computations, they can often help the end users to orient themselves to a particular presentation.
See Appendix C - Bibliography for some leads on sources of digital information.
For hard copy plotted results, Hipparchus Auxiliary Library functions can be used to generate HP-GL/2 (Hewlett-Packard Graphics Language) printer/plotter protocol. These routines have been provided in source form so you can adapt them to any other protocol you wish. Hipparchus does not particularly care what you use. Only the normal caveat applies: any "replacing" function must be syntactically the same (i.e., use the same arguments and return the same values).
The sample programs include copious examples of methods and techniques for generating plotted hard copy of your geographics. For additional information about the sample programs, refer to Appendix B - Galileo and Georama.
When you are producing hard copy plotted results, remember that people will often use this output as an overlay for other graphic material. Also, remember that some clients may attempt to use a ruler and compass to perform other calculations using the hard copy output. For these situations, you must be particularly careful about the projection, scale and viewpoint, and your clients will need to have some understanding of mapping in general. For further information, refer to the text by Davis et al described in Appendix C - Bibliography.
To further explore the possibilities for the graphic presentation of geographic information, we refer you to Appendix B - Galileo and Georama.
Providing graphic application input and output is a challenging element of computing. Hipparchus allows you easily to interface to a GUI of your choice for interactive graphic input and output. The connection is simple and direct as discussed in Chapter 2 - Computing Environments. Once this is done, there are few considerations beyond the obvious when you are rendering output from your application. Some day, when we eventually have access to inexpensive holographic 3D display systems, using the Hipparchus capabilities will become even more exciting.
