CT301

FINAL PROJECT REPORT

 

Degree BSc Computation and Geography

 

Student RN 99004279

 

Project Supervisor Dr. Roger Braithwaite

 

Submission Date 01 May 2003


Abstract

The method used to take glacial mass balance studies are changing. New technology in the form of robotic sampling and GPS (Global Positioning Systems) are revolutionising data capture. With the new data capture techniques new methods of displaying the data and interpreting the results need to be found. 3D Visualisation is one method of achieving the visual display of the data. This project is concerned with the production of a computerised system to visualise the data from two glacial surveys conducted in 1995 and 1996. Using object orientated design techniques and the evolutionary method for the implementation. Transformation of the data from its existing form then use of a database system to store the results after the conversion. The visualisation is created using OpenGL libraries and Visual Basic on the Microsoft Windows Platform. After an initial attempt to generate a TIN (Triangular Irregular Network) built from tessellated triangles was seen to be unsuitable, a terrain map was generated using the heights on sample points that are allocated a position in a 1024 by 1024 grid averaging out points that appeared in the same grid cell. The image system interpolated the points using a linear equation to interconnect the survey points.


Table of contents

Abstract                                                                                                 2

1. Introduction                                                                                        5

1.1 Structure of the report                                                                      5

1.2 Background                                                                                      5

1.3 Project Aims                                                                                    5

1.4 Review of Relevant Literature                                                             6

1.5 Deliverables                                                                                      8

1.6 Overview of the project                                                                     8

1.7 Educational value                                                                              8

1.8 Technical challenge                                                                            9

2. Requirements                                                                                    10

2.1 Functional requirements of the system                                                10

2.2 Non Functional Requirements                                                            10

3. State of the Art                                                                                 12

3.1 Existing Systems                                                                              12

3. 2 Choice of visualisation method                                                          15

4. Design                                                                                              16

4.1 Approaches and Notation                                                                  16

4.2 Conceptual Level Design                                                                    18

4.3 Communication of the design                                                            20

5. Implementation                                                                                 24

5.1 System Walkthrough                                                                        24

5.2 Examination of Important Routines                                                    29

5.3 Switch to Visual Basic                                                                       33

6. Evaluation / Testing                                                                           34

6.1 Testing the system                                                                          34

6.2 Testing Against the Requirements                                                      35

6.3 Evaluating the Approaches used                                                         36

7. Conclusions and Further Work                                                             37

7.1 Conclusions                                                                                     37

7.2 Further work                                                                                  37

8. Acknowledgements                                                                            39

9. Glossary of Terms                                                                               39

10. References                                                                                     40

11. Table of Figures                                                                               41

Appendices                                                                                           42

Appendices                                                                                           42

Appendix A. Program Code                                                                     42


1. Introduction

 

This chapter outlines the aims and gives an overview of the project being undertaken, identifying the work to be carried out. This chapter also provides an evaluation of the background reading and gives some initial ideas for a project solution.

1.1 Structure of the report

 

1. Introduction - discusses the aims in greater depth, suggests the intended outcomes of the project, specifying the form that the deliverables of the project will take. This chapter discusses the learning objectives for the project and educational and technical value.

 

2. Requirements – states the requirements of the deliverable and project.

 

3. State of the Art - compares the aims of the project to existing systems and discusses the need for a new system.

 

4. Design - a detailed design of the system, considering some different possible approaches and details which will be used and why.

 

5. Implementation - provides a walkthrough of the system and examines how closely the design was followed and how the deliverable was created.

 

6. Evaluation/Testing - evaluates to what extent the deliverable fulfilled the requirements of the project and shows how the project was tested. This chapter also examines the approaches used in the project, and asks how successful they were.

 

7. Conclusions and Further Work - outlines the project and presents conclusions. Lessons learned from the project are discussed. Further extensions and improvements to the project are suggested.

1.2 Background

Professor W F Theakstone provided data from two glacial studies, which used Global Positioning Systems (GPS) to record Northing, Easting coordinates along with Height data. The aim of the project is to use this data to create visualisations and make comparisons between the datasets. Two journal articles written by Professor Theakstone and provided with the datasets, explained the sampling methods used. They are examined in the next section.

1.3 Project Aims

The aim of the project is to develop a system to handle Easting, Northing and altitude data for the surface of a glacier and to generate a terrain model and/or visualisation. In the test data set there are two surveys from successive years, so changes will also be investigated between years. 

1.4 Review of Relevant Literature

The two journal articles ‘Digital Terrain Modelling of the Surface and Bed Topography of the Glacier Austre Okstindbreen, Okstindan, Norway’[1] and ‘Changes of snow cover thickness measured by conventional mass balance methods and by global positioning system surveying’[2] are the basis for the project. The second of these articles makes a comparison between the traditional methods and new techniques of glacial surveying using GPS (global positioning systems) devices. The article provides a good argument for the use of technology and explains both sampling methods in great detail.

 

The paper, ‘Digital Terrain Modelling of the Surface and Bed Topography of the Glacier Austre Okstindbreen, Okstindan, Norway’, focuses on the use of digital terrain modelling using TIN networks. It provides the base line from which any visualisation that is attempted needs to start and improve. The papers make use of height contour maps with the survey points marked.

 

A number of books concerned with the geographical aspects of the project were consulted, of which “Geographic Information Systems and Science”[3] proved particularly useful. Not only does it compare several methods of visualising GIS data, it also contains comparisons of different applications. It is well written and has some very good examples but at times can go into too much detail too soon. It also seems to require you to read it almost as if were a web page, constantly switching between the narratives on the page to the various inset boxes which explain a particular topic or give examples. Having said that, it is a very thoughtful text and has proved useful for my project.

 

Next are the books that explain the computing element of the project, namely the OpenGL graphics and the programming language guides.

 

Finally there is “Getting started with 3D - a designers guide to 3D graphics and illustration”[4], which is a primer on the art of 3D graphics, and details the methods of making a “good looking” visualisation. “Getting started with 3D” is not a book about programming. Rather it is about the art of creating a good visualisation. Focussing on computer graphics, the early chapters were especially useful in the descriptions of the art of 3D design, explaining perspective, the science of drawing and atmospheric effects. Later on in the book is a chapter about natural effects including terrain models (pages 60-64). The book provides a very detailed, yet easily comprehensible, synopsis of techniques that need to be considered when creating a 3D visualisation, and poses many interesting questions about creating a visualisation.

 

Also examined were a number of graphics programming websites and books, which will now be discussed.

 

http://Nehe.gamedev.org[5] provided a wealth of OpenGL tutorials, information and ideas. The tutorials in particular are extremely comprehensive and cover in detail the sorts of methods needed to produce visualisations with OpenGL.

 

The book entitled “3D Graphics in Pascal”[6] proved of little use, since its main concern lay with creating line art through programming subroutines. While the mathematics used for the calculations was useful, it did not explain the usage in as comprehensive a way as the OpenGL programming guide. Also the book is rather outdated, being over 10 years old. Although the techniques described are still correct, their value has depreciated since graphical languages simplify graphics programming somewhat.

 

Microsoft’s online documentation for DirectX is fairly comprehensive and the software development kit (SDK) is freely available. However, Microsoft does not provide as extensive an archive of third-party tutorial sites and useful information as found on the OpenGL web page.

 

“OpenGL a primer”[7] is essentially akin to the first few chapters of the OpenGL programmer’s guide and is a fairly basic introduction to OpenGL libraries and techniques. The “OpenGL Programmer’s Guide” goes into far more depth and contains many examples of how and when to use OpenGL, some tutorials and useful programming tips.

 

OpenGL only provides a method of producing graphics so as to be cross platform, and therefore other languages are needed to create the windowing commands. Several languages that can be used with OpenGL were examined. These included C, C++, Java and Delphi. The book “Java - How to program”[8] is very useful, not just a primer to Java itself but also a primer on object orientated design and UML. It has an excellent use of teaching through example and colour coding of code and lettering. On the downside unfortunately, not all of the examples work or are complete (It is a book intended for use with university courses and there is a lecturer’s guide which completes some of the exercises).

 

The “C Programming Language”[9] is a seminal book describing the C programming language. It is concise (being by far the smallest of the programming reference guides), but it does not cover the windowing functions of C, instead concentrating on the different techniques available in the language. Overall it is a very good reference for C.

 

Microsoft’s “Visual C++ Programmer’s Guide” is not like the other programming books, since its primary aim is to show what Visual C++ version 6 can do and how it can be used, rather than teaching how to program in Visual C++.  While it would be useful to show someone how to use Visual Studio, it is fairly useless for the project, at least until enough knowledge about C++ is gained to need a Visual Studio reference guide.

1.5 Deliverables

A program capable of the visualisation of a set of co-ordinates and height data for a given set of GPS data will be produced. Associated documentation will support the computing artefact. The program should also have the functionality either to export the data for use in a GIS system or be capable of calculating changes in volume between the visualised objects.

1.6 Overview of the project

The main activities in this project are:

 

 

The test data for the project exists in the form of two Microsoft Excel spreadsheets.

 

An object-orientated approach will be taken to develop the system, as it offers a better path between the design and implementation than other models. This approach requires the use of object orientated tools. The program is intended primarily for the Microsoft Windows platform.

 

The required resources will include material regarding glacial environments, and literature on the programming languages. Other requirements include compilers, programming tools, operating systems and computers.

1.7 Educational value

The development of the system deepens and expands the author’s knowledge in applying design techniques.

 

The author hopes to become fluent in new computer techniques, including the use of the OpenGL graphics environment and the C/C++ programming language. Likewise, there should be some improvement in management and organisational skills as a result of this project.

 

Furthermore, the project offers an opportunity to expand knowledge of glacial environments personally.

1.8 Technical challenge

Development of a method of turning the raw information comprising the global positioning data into a visualisation represents a technical challenge. This will involve understanding the nature of three-dimensional objects in OpenGL and C++. Adjusting to new languages is always a challenge, and one that must be overcome in order to complete this project successfully.


2. Requirements

The requirements of the project are detailed in this chapter. These requirements were set entirely by the direct customer for the system, Dr. Roger Braithwaite.

 

The requirements cited below build upon the work undertaken by Professor W Theakstone in his glacial studies[10] of Austre Okstindbreen in Norway. Surveys of the glacier have been recorded in Excel spreadsheets, nominally at yearly intervals. Each data set consists of approximately 2000 survey points taken across much of the surface of the glacier. Each datum comprises of a date (optional) and values of Easting, Northing and metres above sea level.

2.1 Functional requirements of the system

Read in data sets

The system must be able to read in the given data sets.

Transform Data Sets

The system will need to be able to transform the information contained in the data sets into a form usable by the system to produce the visualisation.

Provide a visualisation of the GPS data sets.

Given a set of GPS points, the system should be able to display the points in space.

Calculations comparing the two datasets

The system should be able to perform mathematical operations on two (or more) data sets to compare and contrast the differences between them.

Ability to export data for use with GIS packages

Data used in the system should be able to be prepared for export to a GIS package.

2.2 Non Functional Requirements

Ease of use

The system should have a simple interface and be as user-friendly as possible.

Reusable

Code and libraries for the system should aim to be as reusable as possible. This will enhance the portability of the system.

Extensible

In its lifetime the system should be capable of being extended to include new algorithms for comparing the data sets.

Visualisation should complete in a reasonable amount of time

Rendering scenes can be time / processor intensive tasks. In this system the visualisation should be accomplished quickly.


3. State of the Art

This chapter discusses the literature and materials that were used to determine how to proceed with the project. Alternative systems and methods are compared and evaluated.

3.1 Existing Systems

The main task of the system is to visualise the data, and the other methods hinge around the choice of visualisation. There was a multitude of possible ways of tackling the problem of visualising the data, some of which form part of the discussion that follows. 

CAD packages

Computer aided design packages are software designed to model and design objects in two or three dimensions. Popular CAD packages include AutoCAD, Microstation and 3D studio Max. CAD packages allow a great deal of flexibility in design and it would be possible to model the data sets in a CAD environment. CAD packages are not well suited to GIS environments as they use their own notation for positioning and placement rather than absolute co-ordinates, such as longitude and latitude. Indeed many GIS programs such as Intergraph’s Geomedia are a development of CAD packages, expanding the functionality to include special functions and using geo-referencing rather than proprietary units for measurement.

 

CAD systems produce views that are more akin to engineering drawings than pictures. What seems to be required here has more to do with a picture than an engineering drawing. While undeniably, what is done needs to be realistic, the primary emphasis is on visual appearance, not on accuracy as a quasi-engineering drawing from which other measurements can be derived.

 

Finally, mention should be made of the PV-Wave software from Visual Numerics, which is a system designed to represent and produce contour maps, and so would be more than capable of modelling the data sets.

GIS systems

Grid systems are systems in which the data is put into a grid, from which interpolation can be used and a graph of the data produced. The graph and grid data set can then provide a source of information from which all kinds of calculations, including mass balance, can be performed. Grided data sets, however, do not provide for the most thrilling of graphical experiences, their appearance being more utilitarian than aesthetically pleasing or in fact a representation of the actual shape.

 

DEM (Digital Elevation Modelling) and DTM (Digital Terrain Modelling). These are methods used to display results from the Austria Glacier in Professor Theakstone’s article. DEMs use a grid structure on to which the heights at points on the grid are plotted. Once this has been done, lines can be drawn connecting the points together. This method estimates the heights of other points at regular intervals between the survey points by using interpolation. The accuracy can be improved by using splines (curved lines) rather than straight lines.

 

TINs (Triangular Irregular Network) are networks in which a surface is built up from interconnecting triangles. These are 2.5D (x, y and some z co-ordinates) surfaces composed of triangles. Each point of the triangle has special data for Easting and Northing data and attributing data giving the height of the point.  TIN models also allow texture mapping, allowing, for example, a satellite image or aerial photography to be overlaid over the model.

 

Examples of a GIS system include Geomedia by Intergraph and Arcview from ERSI. Each of these systems could be used to perform operations on spatial data and then to produce either a DEM or TIN image of the data, allowing the overlay of a raster images producing to provide the visualisation with greater realism.

Graphics languages

Graphics languages are specifically designed to represent and model graphics using code. Programming languages include OpenGL DirectX and also vector rendering engines such as Macromedia Flash.

 

One of the possible methods of visualising the data sets was to use Pascal. 3D graphics in Pascal were made possible by using pure programmatic techniques. Though it would be possible to execute in Pascal the visualisation would be limited. In fact Delphi (which is a visual language that uses Pascal as its base) has dropped the methodologies expressed in “3D Graphics in Pascal” in favour of using the OpenGL graphics library.

 

Direct X is Microsoft’s graphical language specifically designed for Windows programmers. Direct X was designed to give Windows the sort of abilities that OpenGL allowed in a native format. OpenGL was developed originally for the SGI IRIX platform. Direct X has many advanced functions, yet it has been mainly utilised by games programmers. There is a wealth of material regarding the Direct X API (currently at version 9) available from Microsoft. Unfortunately, although the software development kit is free, using Direct X would both tie the project to the Windows platform and to a certain extent dictate the use of Microsoft’s development tools.

 

Vector rendering platforms offer other possibilities in developing the project. Vector rendering is a method of building images from points, lines and areas, which makes it particularly suited to displaying the GPS data. In particular the emerging technologies of graphical mark-up language (GML), an offshoot of extensible mark-up language for graphics, could allow the creation of the visualisation in a browser. This would be inherently flexible as the Internet is mainly platform independent. However the standards are young and not fully formed. Also, browser-based systems would require a server that would add unwanted overhead. Furthermore, due to the interoperable nature of GML (it is parsed and run a line at a time) it could prove extremely processor hungry when compared to graphical programming languages that are more efficient.

 

OpenGL is a graphical language developed by Silicon Graphics to create a standard set of graphics libraries. These open graphic libraries were designed to be able to enable complex objects to be constructed around a number of primitives. OpenGL allows the production of 2 and 3 dimensional models and scenes. It also allows for lighting, perspective, viewpoints, atmospheric perspective shading and texturing.

 

The OpenGL libraries and tools have been ported from IRIX to virtually all versions of UNIX and Linux and also to Apple OS and Windows. However this cross platform nature leads to a minor problem. OpenGL has itself no windowing commands, so it requires another language such as C/C++ to create the windowing functions and make API calls to the operating system. This increases the learning curve somewhat since it would require the author to learn both OpenGL and a supporting language at the same time.

 

Method

Advantages

Disadvantages

Adapt GIS system

Less programming involvement

Built in methods of calculations

Possible limitations of GIS system

Quality of the visualisation might need to be sacrificed

System would be tied to GIS package

Use CAD package

Good visualisation

Less programming involvement than new system

Doesn’t use geographical references

System would be tied to CAD package

 

Bespoke new system

Tailor made solution

Most extensible choice

 

Most amount of programming

Need additional features to interface with external packages

Figure 1 Comparison table of methods


3. 2 Choice of visualisation method

It was decided to use Open GL - an open and cross platform graphical language. It is extensible and should be able to output a very high quality visualisation of the data. Indeed it is used in many 3D packages because of its ability to produce high quality imagery. With Open GL though there is a need to program a system to input the raw data into Open GL. To do so, it was planned to use either C or C++ as they are both interface well with Open GL and can create code that is cross platform.

 

While this might be considered a “re-invention of the wheel” by implementing features already included in a GIS package, it does offer several advantages. Firstly a considerable amount of time might be spent on a GIS package, working against its limitations, as they are general systems, not specifically designed to solve this particular problem. Although a GIS package would provide many tools to analyse the data, it would not necessarily be the ideal one for the visualisation. 3D modelling packages would provide a very good visual output but would not have inbuilt tools to handle the calculations.

 

Secondly it would be prudent to develop towards a cross platform or portable system. It would be hard to do this by working with an existing proprietary product. For example, Arcview is one of the few programs that appear on more than one platform (Microsoft Windows).

 

Both OpenGL and C++ are object-orientated, suggesting that an object orientated design process be adopted. Object orientation allows better modelling of real world objects. Object orientation flows from the design to the implementation stage in a clearer manner than other methods such as the waterfall process model.


4. Design

This section discusses some of the different methods that could have been used to design the system and comments on the choices made. A conceptual level design is presented together with a description of the design.

4.1 Approaches and Notation

The problems the system design must overcome include: -

·         Converting the GPS points into meaningful and useful data.

·         Forming triangles from neighbouring points.

·         Performing the visualisation.

·         Comparison of different data sets mathematically.

·         Exporting the resultant information.

 

The evolutionary method will be used, as the uncertainty of the project’s outcome is low but the complexity is high.  The program will be built from modules that fulfil the different functions of the project, database, visualisation, import, compare and export. The modules will interact through a central application, which will have a standard windows interface.

 

Unified Mark-up Language (UML) will be used to explore the system design; the UML notation will then be used as a direct guide when building the system.

 

Currently the data is in the form of date, Northing, Easting, metres above sea level and time of sample. There are two sets in this form, each containing over 2000 results. The data is spatial in nature, which means it has slightly different characteristics from non-spatial data. Spatial data describes the real world. It has a structure dependent on the complexity of the object being represented, and therefore it can be large in volume, so storage considerations are important. Possible ways of storing the data are in a traditional flat file, use of the CSV documents as is, or in a database, either relational or object based.

 

These particular surveys and others could be loaded on to the system every time a visualisation is needed. However a better method would be to store the results in a database system. The decision to use a database allowed a wide range of standard functions to be accessed. Instead of having to program routines to manipulate the data, SQL statements can be used. Take, for example, a select query to recover all the points for a portion of the glacier over a certain height. In a flat file system functions to work with the data would have to be written. Using a database allows others to build queries and add new data to the system with comparative ease.

 

There are a number of different database systems that could have been used, from a home-grown one to a single user database engine, right up to a full blown one. Alternatives included: -

·         mySQL

·         Postgress

·         Access

·         MS-SQL Server

·         Oracle

 

A home-grown system would need to be very complex and would mean that the tools that are freely available in database products would be absent.

 

The database systems can be split into two broad categories, firstly the open source products, mySQL and Postgress. Next are the commercial products, ranging from Microsoft Access, the standalone database, to the top of the range multi user systems from companies such as Oracle, IBM and Microsoft. Price considerations excluded MS-SQL Server and Oracle; Access might be too lightweight to deal with the data and would hinder a multi-user environment.

 

A reference is needed to recall the different studies, and although this search could be based on a time sel