4D Geographic Information Systems - Shoreline Recession in ...home.exetel.com.au/agl/files/Eon_Project_FINAL.pdfusing the open source GIS software called GRASS (geographic resource

4D Geographic Information Systems - Shoreline Recession in Eonfusion

KGG455: Spatial Research Project 2009

Alex Leith

AcknowledgementsI would like to thank my supervisor Arko Lucieer for introducing me to the team at Myriax software

and for providing excellent guidance, advice and feedback. Also Warwick Gillespie, Matt Dell and Brett

Muir at Myriax for support in learning the ins and outs of the software, general assistance and for

helping with the User Coding Environment respectively. A special thanks to Chris Sharples for helping

to narrow down the topic of research and for providing the coastal vulnerability data. Finally I want to

thank my partner, Simone and two children Isaac and Ella for all their patience, love and

encouragement.

ii

iii

Executive SummaryThis project investigates the use of a time varying geographical information system (GIS), otherwise

known as spatio-temporal GIS or simply 4D GIS. The concept of GIS is briefly defined, 4D GIS and

some current examples are introduced. Finally an application of 4D GIS, involving coastal recession, is

described. A simple model of sea level rise and inundation events due to climate change and a more

comprehensive model of the resulting recession are documented. This recession and the rising sea level

is visualised in an area near Hobart in Tasmania, Australia. Eonfusion, a cutting edge 4D GIS system

developed by Myriax Software of Hobart, Tasmania, has been used for all modelling and visualisation

and has proved a very effective tool.

iv

Table of Contents

Introduction.................................................................................................................................................. 1

Aims/Objectives.............................................................................................................................................3

Literature Review.......................................................................................................................................... 4

Geographic Information Systems................................................................................................................4

4D Geographic Information Systems.........................................................................................................4

Past practices and Current research.............................................................................................................5

Eonfusion.........................................................................................................................................................5

Sea Level : Past, Present and Future............................................................................................................6

Storm Surge Events........................................................................................................................................7

Erosion Modelling.......................................................................................................................................... 9

Sea Surface Models.......................................................................................................................................10

Eonfusion – an Introduction......................................................................................................................11

Data input, processing and output....................................................................................................... 12

API and User Coding............................................................................................................................. 13

Research Methodology.............................................................................................................................. 15

Data Sources..................................................................................................................................................16

Sea Level Rise and Inundation Parameters...............................................................................................16

Shoreline Erosion Factor.............................................................................................................................17

DEM thinning...............................................................................................................................................18

Recession Procedure ................................................................................................................................... 19

Buffer..............................................................................................................................................................22

DEM modification....................................................................................................................................... 24

Final Visualisation Model............................................................................................................................24

Results.......................................................................................................................................................... 27

LiDAR Thinning...........................................................................................................................................27

Buffer..............................................................................................................................................................27

v

Recession........................................................................................................................................................34

Sea Level Rise and Inundation................................................................................................................... 34

Comparison with Clarence Council (WRL) Report................................................................................34

Discussion....................................................................................................................................................36

Problems and Shortcomings.......................................................................................................................36

Opportunities for Further Study................................................................................................................37

Conclusion................................................................................................................................................... 39

References....................................................................................................................................................40

Appendices.................................................................................................................................................. 43

Appendix 1: Krill Demo..............................................................................................................................43

Appendix 2: Sample Code: Buffer Operator............................................................................................45

Appendix 3: Shoreline vulnerability (erosion factor) maps................................................................... 50

List of FiguresFigure 1........................................................................................................................................................................7Figure 2........................................................................................................................................................................9Figure 3......................................................................................................................................................................10Figure 4......................................................................................................................................................................12Figure 5......................................................................................................................................................................15Figure 6......................................................................................................................................................................17Figure 7......................................................................................................................................................................18Figure 8......................................................................................................................................................................19Figure 9......................................................................................................................................................................19Figure 10....................................................................................................................................................................21Figure 11....................................................................................................................................................................22Figure 12....................................................................................................................................................................26Figure 13....................................................................................................................................................................32Figure 14....................................................................................................................................................................33Figure 15....................................................................................................................................................................35Figure 16....................................................................................................................................................................35Figure 17....................................................................................................................................................................36Figure 18....................................................................................................................................................................43Figure 19....................................................................................................................................................................44

vi

IntroductionGeographic information systems (GIS) are being used increasingly widely. There is now a very large

volume of spatial/geographic data available and more data are geographically referenced everyday (Li

& Kraak 2008). A logical extension of this is to give these data a temporal aspect; a place in time. There

has not emerged a unified method of visualising temporally referenced data. One simple method of

including the temporal structure in GIS is to give it a time tag (a relational model), simply an attribute

which holds a time (either a fixed point or band of time) in which the event occurred. Another is called

the object oriented approach , which seeks to capture “the complex semantics of time” (Goralwalla et al.

1998) or, in other words, the meaning of this representation of time. Another more simple method of

including time is to use it as a fourth spatial dimension.

There are currently projects in GIS which include the temporal aspect, and there is discussion on

methods of visualising time-based information but until now there has been no single piece of software

explicitly designed to handle time and space in a classic GIS environment. Most spatio-temporal data

analyses are done outside of a GIS and brought back into an environment for visualisation purposes

(Hennecke 2004). These visualisations are usually simple: a time series or two dimensional colour

coded change map. Sometimes an animation will be exported from a piece of software to be displayed

using another. Herein lies the reason for this project: to examine the utility of a 4D, real-time,

integrated GIS environment for the modelling and visualisation of complex time tagged data. The

ability to move through a modelled sequence of events in time and space will be of great benefit to the

chosen topic of investigation. The 4D GIS environment will be an increasingly popular method of data

manipulation and visualisation into the future.

Eonfusion is an actively developed piece of software, authored by Myriax Pty Ltd in Hobart Tasmania.

The Eonfusion website <http://eonfusion.myriax.com> refers to the product as “a unique 4D

software application that provides cutting-edge processing and visualisation of time-varying spatial

data”. This time-varying aspect is to be investigated in this project with a number of examples in the

use of Eonfusion. The major component of this study is a contribution to Myriax's climate change and

coastal inundation model, with an investigation and preliminary implementation of a shoreline

- 1 - Alex Leith | 027986

http://eonfusin.myriax.com/

recession/coastal erosion model.

Much work has been done in erosion modelling (Bruun 1988; Cowell et al. 1992; Stolper et al.

2005) and also with inundation modelling in various software (Google Earth being a notably

prominent example). There has been a study done locally (WRL 2008) for the Clarence City Council,

which focussed on both inundation and shoreline recession modelling in the Derwent Estuary,

Tasmania. There is, however, a lack of studies incorporating both erosion due to sea level rise and

inundation of these eroded regions. Coastal recession due to global sea level rise - as predicted in

current climate change models (IPCC 2007) -will have an impact on the severity of inundation events,

although there is only limited research in the area (Church et al. 2008). In addition to increased

erosion, sea level rise will cause an increase in the frequency and possibly the severity of storm events

(McInnes et al. 2007). The modelling and visualising of both the probable sea level rise and

consequential coastal recession due to future climate change within Eonfusion's integrated spatio-

temporal environment should be a valuable way of understanding potential future impacts.

Accompanying this report is an online resource containing data files, images, video and a brief

summary. The web address is <http://home.exetel.com.au/agl/eonproject/>. Since the

visualisation of data is a major component of this project, the website will be integral in understanding

the results of the research.

Spatial Research Project 2009 - 2 -

http://home.exetel.com.au/agl/eonproject/

Aims/Objectives

The aim of this study is to model and visualise coastal recession, sea level rise and inundation events as

predicted by current climate change research by implementing a recession model in a spatio-temporal

GIS environment. The objectives are to:

1. Review the literature on spatio-temporal (4D) modelling, visualisation and coastal recession.

2. Become familiar with the basic functionality and user coding environment of Eonfusion, a new

4D modelling and visualisation software.

3. Collect appropriate starting values for rates for sea level rise and recession based on a literature

review. These values should be the best evidence available for the region but may contain

temporary assumed values where they could easily be substituted for better values as they

become available.

4. Design and implement a model for eroding a shoreline in Eonfusion within the new user-

coding environment.

5. Visualise sea level rise and coastal recession over time in Eonfusion. These visualisations will be

made easily accessible and appropriate for a wide audience of non technical persons. The

presentation of online video of a dynamic view of a changing shoreline will be investigated.

6. Compare the model results to previous and current research.

- 3 - Alex Leith | 027986

Literature Review

Geographic Information Systems

GIS are software run on a standard desktop personal computer which aim to import, process and

display geographical information - that is, information with location. Most popular GIS are commonly

referred to as being 2.5D, which is to say they are limited to two and a half dimensions: X, Y (or

latitude and longitude) and a single height or elevation value. Two standard data types exist in GIS:

raster data, which is a regular grid containing a value or values of attributes in each square; and vector

data, which contains vertices and either 1D or 2D topology (connectedness). Some GIS have the ability

to use the elevation attribute - often in a raster data structure - to create a 3D surface and to drape

other data layers in order to create an environment for visualisation purposes. True 3D data has the

ability for multiple height values for each X,Y coordinate so that each vertex in a vector, for example,

requires three coordinates to place it in space. An extension of this is to have coordinates which vary

with a fourth attribute: time.

4D Geographic Information Systems

4D (spatio-temporal) GIS has been discussed for some time, (for example by Hazelton et al. 1990), but

it is only recently that desktop computers have realistically been able to handle such high volumes of

data for dynamic display. Google Earth has been used extensively to visualise data; although there are

only limited examples of it being used in the literature, there are many websites dedicated to sharing

and promoting Google Earth as a visualisation tool. Data in Google Earth can be tagged with time, for

either a single point in time or a period of time, and from here may be seen to change through time.

The drawback with Google Earth is the lack of modelling and analysis tools: it is simply a visualisation

tool with the ability to display 3D and 4D information quickly, easily and portably. Brown et al. (2006)

used a flight simulator to visualise data generated from their erosion modelling, utilising modern

software to generate “photo realistic scenes”. These approaches lead to a better understanding of the

data through their visualising and cognising by researchers. There is an advantage from integrating the

modelling and visualisation of data in a single package which this research aims to demonstrate.


Past Practices and Current Research

Brown et al. (1995) describe what they call the “multidimensional dynamic cartographic approach”,

which is essentially an early foray into the realms of 4D visualisation. They examine 3D terrain models

using the open source GIS software called GRASS (geographic resource analysis support system). Their

approach displays a 3D surface and can output an animation by following scripts; it is not real time but

does investigate 3D spatial queries and is a very early implementation of 3D surfaces in GIS, varying

over time.

A recent example of utilising time in the presentation of data is the Allosphere (see Höllerer et al.

2007),which is an immersive 360-degree 3D screen inside a 10 m diameter sphere. The system, which

is still early in its implementation, will be composed of stereographic images from multiple projectors,

and 3D sound from hundreds of speakers. This system is designed so that up to 30 researchers, artists,

students or policy makers can stand within the sphere and immerse themselves completely within a

data model, exploring the structures visually and interactively. Images, colours, shapes and sounds are

presented – all changing through time and giving insights to the surrounding structures. The

Allosphere contains a cluster of computers to generate real time graphical and auditory visualisations

which can be manipulated to investigate objects (Höllerer et al. 2007).

Both of these examples demonstrate the advantages of the visualisation of models, and the Allosphere

aims to give insights only available with real time interaction. Brown et al. state that “by integrating

advanced visualisation capabilities and modelling tools … researchers are better able to evaluate a

model's validity, explore possible causes of unexpected exceptions, tune modelling parameters and re-

visualise the results in a methodical, intuitive way”. It is also apparent that the sharing of information

with the lay person is easier if it is presented in such a way that it is easily interpreted and that such a

person is already familiar with (such as a 3D fly through).

Eonfusion

Eonfusion is essentially a scaled down version of the computation systems required by the Allosphere

project, but without the sound component. Eonfusion has been designed to work with four dimensions

from the outset and provides graphical methods to load, manipulate and visualise data. Eonfusion

handles time, or an arbitrary fourth dimension, using a slider at the bottom of the view. This slider can

be expanded to see a period of time and there are controls such as play and pause to allow one to play

through the data set. Each piece of data can contain a “Datetime” attribute, in days, hours, seconds etc.

- 5 - Alex Leith | 027986

which will automatically be bound to the time slider.

This fourth dimension empowers the user by enabling real-time interaction with the visualisation of

data changing over time. Recently Eonfusion opened up an application programming interface (API)

which enables users to create new operators. This scripting environment enables a user to create

complex models outside of the standard set which come with the software. This cutting edge real time

visualisation engine and powerful API and scripting environment will be fully utilised in the modelling

and visualisation of coastal recession and sea level rise as predicted by climate change.

A simple example illustrating the power of 4D visualisation is included in Appendix 1 (see the web

page at <http://home.exetel.com.au/agl/eonproject/> for a video) where around 30 krill

swimming in a fish tank have been visualised. This form of 4D viewing of schooling fish enables one to

quickly examine a data set visually for things such as an individuals' proximity to neighbours.

Sea Level: Past, Present and Future

Historically, sea level has been a dynamic feature and it is unusual that it has stayed relatively static, as

has been the case for the past few thousand years (Church et al. 2008). It has been shown that current

rates of sea level rise are “an order of magnitude faster than the average rate over the previous several

thousand years” (Church et al. 2008). Presently, the mean sea level is rising at a rate of around 3 mm

per year, although there is some regional variability (Church & White 2006).

In order to estimate future sea level, a number of factors need to be taken into account. The most

influential two of these factors are the rise in mean sea level due to thermal expansion of the oceans

and melting of land-based ice (IPCC 2007). The Intergovernmental Panel on Climate Change (IPCC)

has predicted a rise in mean sea level over the next 100 years between 0.18 m and 0.59 m (IPCC

2007), although these don't include a contribution from melting ice shelves on Greenland and

Antarctica. These ice shelves are included in a footnote in the IPCC document, increasing the upper

limit by 10 to 20 cm. Recent research by Rahmstorf (2007) suggests that this is on the conservative

side and shows that a range of between 0.5 and 1.4 m is consistent with the current observations (see

figure 1). Current observations of sea level from satellite altimeters are tracking the very highest limit

of the IPCC models.



Church et al. (2008) state that “observed sea level has been rising more rapidly than the central range

of the IPCC model projections and near the upper end of the total range of the projections”. This

implies that we should prepare for and lend heavier weight to these higher values of future sea level

rise.

Storm Surge Events

On top of the rise in sea level, we have extreme events (inundation events associated with storm surge

low pressure events) which, though unlikely to increase drastically in severity, will increase in

frequency (Woth et al. 2006; McInnes et al. 2007). That is, a storm surge event which would be

expected to occur once every one hundred years now may be expected every four years in 2070. A

storm tide occurs when atmospheric lows combine with wave runup (the result of wind affecting sea

level), and a high tide to create an extreme sea level event. McInnes et al. (2007) report figures for

storm tide levels between 0.93 and 2.15 m for areas on the south coast of Victoria in 1990. The

predicted figures from the same study for 2070 are between 1.59 and 2.72 m. These are figures for a

100 year annual recurrence interval (ARI) event.

- 7 - Alex Leith | 027986

Figure 1: Graph of sea level rise predictions. The green areas are IPCC predictions from 2001, the pink bar from IPCC 2007. The red line above the pink bar shows ice sheet contributions from Greenland and Antarctica. Note the inset image showing observation data which is tracking the worst case models (image source: Church et al. 2008a).

Erosion Modelling

Historically the 'Bruun Rule' of shoreline erosion (Bruun 1988) has been used to approximate changes

in beach profile due to sea level rise. This rule is based on the assumption that the sediment eroded

from onshore areas will be deposited offshore (see figure 3). The U.S. Environmental Protection

Agency (2009) states that this can be approximated with the simple rule that the horizontal erosion

will be equal to around 50 to 100 times the rise in mean sea level. This is a complex problem in terms

of implementation into a software modelling environment as this is a 2D model, while we are dealing


Figure 2: Showing the combination of factors which need to be taken into account for storm surge events. A high tide, with the addition of wave setup (wind forcing of water), wave runup (wave splashes), and increased sea level from low atmospheric pressure systems. (Image source: http://www.cmar.csiro.au/sealevel/sl_drives_short.html)

Figure 3: Showing the basic principles of the Bruun Rule. Note that the equation can be approximated to R = S x EF where R is the distance a shoreline will recede, S is that change in sea level and EF is an erosion factor, usually between 50 and 100 as a rule of thumb.

with 3D constructs. The Bruun rule has been the rule of thumb for erosion modelling for around 50

years and although it has been criticised, see Cooper and Pilkey (2004), the simplicity of the model

and its ease of application has led to it being widely used.

A more comprehensive method of erosion modelling is the Shoreface Translation Model (STM). This is

a computer model developed by Peter Cowell at the University of Sydney. The STM incorporates

sediment inflow and outflow and works on the beach as a system rather than the Bruun's constraint of

using a 2D profile (Cowell et al. 1992).

Other approaches to modelling erosion such as GEOMBEST (Stolper et al. 2005) and SCAPE (Brown

et al. 2006) incorporate multiple variables to more closely represent the real world. These models

incorporate parameters such as sediment budgets (sources and sinks such as rivers or offshore loss),

wave climate, geology and stratigraphy. These two recent approaches are complex, comprehensive and,

although still in need of validation, could provide an excellent input to this recession modelling.

Sea Surface Models

Sea level rise will not be uniform across the Earth and local variations will also exist (Church et al.

2008). This study uses a simple “bathtub” model of the sea surface and sea level rise, where all areas

below a certain elevation will be inundated. An alternative was used by Poulter and Halpin (2008)

where a raster model is inundated if it is both below a certain elevation, and connected to a neighbour

which is covered by water. The bathtub model is used here for simplicity and due to the processing

time it would take to find areas which are inundated in a connectivity model.

Eonfusion – an Introduction

Eonfusion adheres to the standard set of GIS features such as importing and storage, manipulation and

processing, and the output or visualisation of data. A brief introduction to the basic concepts of

Eonfusion, how it works and how one handles data follows.

The prominent data structures in Eonfusion are vector-based, although raster data is supported. Data

structures consist of the following elements in order of generalisation most to least:

1. vector set groups: consisting of one or more data sets, forming a handle on related data

structures

2. 0D, 1D, 2D or raster features: consisting of a group of features of particular topological

- 9 - Alex Leith | 027986

dimension, e.g. 0D for points, 1D for lines and 2D for surfaces

3. feature: single set of connected vertices, e.g. poly line or surface

4. vertex: one point on a feature, a single vertex may have connections to one or many 0D,1D

and 2D primitives and be incorporated in one of more features

5. primitive: a single point (0D), one segment on a line (1D), one triangle on a surface (2D). A

primitive is a handle for an element of a feature.

It should be noted that the dimensionality of vector sets in Eonfusion is based on topological

dimension. This refers to the connectedness of vertices, i.e. a 0D point is not connected to any other

points whereas a 2D surface has connections in two dimensions.

Data input, processing and output.

The software provides a standard set of tools to create surfaces or lines from input data, drape imagery

over a surface or DEM, to seamlessly include time coupled data and to view these in three dimensions

and through time. Starting the program brings up the 'dataflow' view, which contains 'dataflow objects'

which point to the representation of your models (see figure 4). In these dataflow icons are a number

of further tiles which represent individual 'dataflow objects' such as:

• data sources: a reader which will point to a file or database on the disk from which to source

data


Figure 4: Showing the structure of an Eonfusion dataflow, the blue objects are data sources, the green are operators and orange scenes. This scene is a simple bathtub model of sea level rise.

• operators: these are the tools, such as 'generate surfaces', which combine, fuse or otherwise

modify data

• data writers: which can output data to file, such as KML, shapefile or tabular text

• one or more scenes: these are the viewer dataflow objects.

All the dataflow objects are connected with 'pipes' and have a coloured border which represents their

stage of computation. A green border indicates data are loaded and ready to go, blue indicates an

operation is being carried out, and red indicates error. A user can pipe one or more dataflow objects

into a scene, open the scene and add a visualiser to the data structure. Further modifications and rules

can then be applied to the visualiser such as colouring points according to attribute values, creating

halos around points according to other rules etc.

API and User Coding

The API and User Coding Environment (UCE) is still under development, but the author has been

given access and guidance in the implementation of operators in the current UCE. This coding is done

in C# (pronounced “C sharp”) which is an object-oriented programming language developed by

Microsoft. The syntax of the language is very similar to the Java programming language, and scripting is

done using Microsoft's Visual Basic 2008 Express Edition. An example operator script - BufferLine.cs -

is shown in Appendix 2. A simple description of the general process of scripting is as follows:

1. Define a structure for input data types.

2. Assign (bind) input data to an object (variable), effectively giving the data structure a name.

3. Carry out the operations on this structure such as iterating through the vertices on a surface or

traversing a line.

This process is indicative only and in practice the UCE makes for a very powerful environment, which

can be used to automate repetitive tasks, implement novel algorithms or carry out complex

computations.

A component useful for navigation of features in a vector set group involves primitive handles. These

can be conceptualised by thinking of the primitives (components of a surface or line) and placing a

handle on one of these. For example, a handle can be placed on a line at a single section (the section

being the line primitive), then can perform movements along the line by swapping vertices (reversing

- 11 - Alex Leith | 027986

the direction) or flipping over a vertex. These two operators are the essential components of data

structure traversal and can be used to complete many tasks. An example in the BufferLine.cs script is

finding the start of a line:

In this example the second last line moves to the next line, and will continue to do so

until the previous primitive is the same as the current primitive (there is another case

handled in this code which deals with world indices, but these are beyond the scope of

this example). Once the conditions are met, the while loops will stop iterating and we

know that we are at the start of the line. From here we can swap vertices and flip over

to travel along the line performing whichever functions are desirable along the way. A

similar process is also available to move around surfaces.


// Iterate along the line until we hit one of our exit conditionswhile ((previousPrimitive != lineHandle.Primitive) && (lineHandle.Dest.RowIndex != 0)) { previousPrimitive = lineHandle.Primitive; lineHandle.SwapVertex().FlipOver(); }

Research MethodologyThe primary focus of this research is coastal recession, and this is to be visualised and combined with a

simple bathtub model for sea level rise and inundation events. A bathtub model refers to using a flat

surface for water level, this is a simple approximation which assumes that sea level will be uniform

across the study area. The chosen study site is South Arm on the Derwent Estuary in Tasmania (figure

5) and in particular the north-western end of the beach. This area was chosen as it contains two

different erosion types along its shoreline and has current and freely available LiDAR data.

- 13 - Alex Leith | 027986

Figure 5: An image of the study area near Hobart, Tasmania. The area shown in blue in the main image is the region on which recession was modelled.

Data Sources

The following data sources are used in the model:

• LiDAR DEM: this data has been acquired by the ACE CRC and made available under a

permanent, irrevocable, free license. Tiles were downloaded from the LIST

<http://www.thelist.tas.gov.au/> on the 12th March 2009. LiDAR is a form of laser scanning

captured from an aeroplane which gives a very high density and good vertical resolution data

set.

• Coastal vulnerability layer: Chris Sharples provided an ESRI shapefile containing coastal

vulnerability values. This data set forms part of an indicative first pass assessment of coastal

vulnerability described in Sharples (2007).

• Aerial/satellite imagery: Satellite imagery, acquired from Google Earth, imagery is available

for personal use. The image was exported from Google Earth Pro and georeferenced in Arc

GIS.

• Sea surface heights: These were generated, in a simple text file, and have been assumed at

around 1 cm of sea level rise per year over 100 years. These values was chosen first for

simplicity and second as a realistic worst case scenario as forecast by recent research

(Rahmstorf 2007; IPCC 2007).

Sea Level Rise and Inundation Parameters

This study adopts a simple linear sea level rise model starting at 0 m Australian Height Datum (AHD)

above mean sea level in 2000 and ending in 2100 at 1 m. These values are simplistic and intended to

give an indication of the effects of a worst case scenario (IPCC 2007). The model is designed such that

better values may be included in the future. The values are at the higher end of the expected range of

future sea level rise. The Clarence Council report (WRL 2008) uses a similar upper value for 2100 at

0.9 m for mean sea level.

For inundation, previous studies have used values of around 1.6 m for total storm surge levels. This

value is within the range predicted by McInnes et al. (2007) and will be adopted for this research.


http://www.thelist.tas.gov.au/

Shoreline Erosion Factor

Most if not all erosion models, with regards to sea level rise and coastal recession, have an output

consisting of an erosion factor or similar measure of recession for a certain area. This erosion factor (or

recession distance) is generally in the range 50 to 100 times the sea level rise for an area for a period of

time. This research uses Chris Sharples' coastal vulnerability data (Sharples 2007) to assign coastlines

with an erosion factor. These factors are:

• non: not readily erodible, with an erosion factor of 0, these regions will not change

significantly

• mid: medium erodibility or vulnerable to slumping, with an erosion factor of 20, these regions

will recede but only a small amount

• high: readily erodible or prone to recession, erosion factor of 60, these regions will recede

significantly.

Appendix 3 contains maps showing the original classification and the reclassification as used in this

study. The original classes were assessed subjectively and assigned as shown in figure 7 into three classes

of erosion rates. These rates are used as a parameter for a recession model.

- 15 - Alex Leith | 027986

Figure 6: Early inundation model showing a worst case scenario storm surge event in 2100.

Although these erosion values have been assigned arbitrarily, they are based on vulnerability classes

from (Sharples 2007) and as such will make realistic and relevant starting values. It is intended that as

better models become available these could replace the starting values in the present recession model

to achieve more rigourous results.

DEM thinning

Since LiDAR data is of such a high spatial resolution, it is important to be able to decimate or thin the

data to reduce computation time. This can be done without significantly affecting the accuracy of the

representation of the terrain (Mandlburger & Briese 2007). In this study, LiDAR thinning was

implemented as an opportunity to become familiar with some of Eonfusion's functions. The process

identified by Mandlburger and Briese has been modified with the addition of measures of similarity

such as slope and aspect. Points are removed from the datasets if they satisfy the following conditions

(X values are user-defined thresholds):

1. if the maximum distance to a neighbour is less than X1 (this has not been implemented in the

final model due to time constraints) then

2. if the absolute value of the maximum difference in slope to neighbours is less than X2 and the

absolute value of the difference between the average slope of neighbouring points and this


Figure 7: Current reclassification of Sharples' Vulnerability classes into three erosion factor classes.

point is less than X3 remove the point

3. or else: if the maximum difference in height between this point and its neighbours is less than

X4: remove the point.

This has been evaluated, although the distance component was not included, with several different X

values and resulted in a reduction in points at around 30% with very little perceivable difference. The

technique could be refined further to attempt to achieve higher compression. The possibility of greatly

simplifying terrain above a certain height (as this will not be affected by erosion) has been raised.

Another possibility is the merging of the DEM with the coastal vulnerability layer and affecting

important (vulnerable) points less than unimportant points.

- 17 - Alex Leith | 027986

Figure 8: Flow chart showing the methodology and thinking behind the simple LiDAR thinning process. Note that step one, checking distance, has not been implemented.

Recession Procedure

The final plan for this study is to create a general recession operator for Eonfusion which could be used

in any region provided the input data sets of elevation and erosion factor. Ideally it would:

1. locate the land sea interface for a particular time and create a polyline here

2. given an erosion factor at each point on this line

3. affect the DEM by pushing back to shoreline by a distance (this distance being a function of the

erosion factor for the particular area and change in sea level for the period

4. reconcile the modified DEM (which will contain a cliff at the edge of the affected area) with its

surrounds

5. repeat steps 1 through 4 for the required time period; and

6. visualise the results.

Step 1 proved difficult and a compromise has been made given the time constraints of this study. The

procedure as it stands is to:

1. use the coastal vulnerability line, from Sharples (2006), as the shoreline

2. buffer around this line as a function of time and erosion factor

3. affect the DEM and give affected points a height for this particular time

4. repeat steps 1 through 3

5. visualise the results.

Some shortfalls of this method are that the process is not iterative, does not include accumulative

shoreline changes, and does not deal with possible accretion of material off shore and potentially along

the shoreline. The reasons for the change will be discussed later, as will possible future enhancements

to this model. Figure 9 shows the dataflow for the recession model.


Buffer

A buffer was chosen as a method of identifying areas which would be affected by erosion. The buffer

size is determined by the erosion factor specific to the polyline input and the amount of sea level rise

during a time period. Since sea level rise has been assumed at 1 cm per year, we can find the required

buffer distance by the equation:

buffer distance=time period×erosion factor100

The result of this operation will be that areas that will be affected by shoreline recession will be inside

the buffer area.

Since Eonfusion currently lacks a buffer operator, one of the key tasks in this study was to implement a

buffer operator in Eonfusion's user coding environment. The buffer takes in a line data set and, given a

number of years as a parameter, will create a 2D surface which represents the affected area of the

DEM.

- 19 - Alex Leith | 027986

Figure 9: Recession dataflow shown in Eonfusion. This image was captured when the third 'intersect vector sets' operator was running. The process which is being carried out includes importing data (blue objects), iterative computations of buffering of shoreline and affecting of DEM and finally the output of the results to file before visualisation.

This buffer was implemented with some compromises. A buffer about a line generally will consist of a

cap at either end of the line and points running parallel to the line on either side. The complexity arises

in joins between line segments. Points can be created perpendicular to the line, and caps created at

each end (see figure 10a). Some joins between segments can be solved by creating a point on the

outside of the intersection and by replacing the two points on the inside with one (see figure 10b).

The complexity arises when complex and rapid changes in direction occur (figure 10c). In practice it


Figure 10: Illustration of a buffer process. Part a) shows an implementation with parallel points and caps. Part b) shows possible solution, using a point created either side of a vertex to fill the gaps and reduce the number of points created. Part c) shows a problem region where the complexity of the solution becomes greater. Part d) shows the current implementation (a screen shot from Eonfusion) which covers all necessary areas, but creates multiple redundant points.

was decided that the redundancy of points caused no great problems and that the outside points would

be filled in as part of the intersection procedure, described later. Figure 10d shows how the operator

works in practice, it creates points perpendicular to each line segment and adds triangles to a 2D

feature as it moves along the line (Appendix 2 contains the code for this operator). The buffer process

can be summarised as follows:

For each feature:

1. find the start of the line

2. create a cap at the front of the line, create triangles for this cap

3. create perpendicular points, relative to this section of the line out from each vertex, create

triangles for this segment and connect this segment to the last (this works for caps also)

4. check the angle of the intersection of two line segments

• if sufficiently sharp, create outside point and merge inside points

• move to next line segment

5. repeat 3 and 4 until the end of the line

6. create a cap at the end, create triangles for the cap.

The triangles are added to a 2D surface feature (similar to a polygon) one at a time. An interesting

complexity with this triangulation is that triangles have a direction, i.e. they have a top and a bottom.

This direction is determined by the order in which the vertices are added to a triangle. A small section

of code was added (see the 'addTriangle' method in Appendix 2) which uses vector maths to determine

the order required for vertices, abstracting the triangle direction issue and ensuring all triangles face

the right way. If triangles are not all the same side up they render differently when visualised in

Eonfusion.

DEM Modification

Eonfusion includes some built-in functions, which are innovative, involving the fusion of datasets.

Fusion in the context of Eonfusion involves the merging of vector sets to create a link on features

pointing to nearby other features. Fusion allows for the transfer of information between two or more

datasets based on coincidence. One of these fusion operators, the intersect vector sets operator, was

used to combine the buffer generated about the vulnerability layer with the surface model, created

- 21 - Alex Leith | 027986

from thinned LiDAR points. The output of this operator is a vector set group consisting of a surface

(2D vector set) with all vertices from the input vector sets. The vertices that are members of the

surface primitives (triangles) now contain a value that holds the number of surfaces using the vertex.

This is useful as we can deduce those sections of surface which are part of both the buffer and the

DEM. The height of the vertices can now be adjusted, dropping the affected area of the DEM to the

required height.

This process was carried out four times, so that each point on the DEM contains five heights, one

original surface height and for each new epoch: 2025, 2050, 2075, 2100. The vertices are also given a

date for each epoch so that a visualiser can be assigned.

Final Visualisation Model

The final dataflow shown in figure 11 consists of the following major components:

1. Sea surface: this is a set of operators which create a simple flat sea surface with an elevation

changing over time.

2. Elevation model: containing five surfaces each with specific heights for a certain periods of

time.

3. Imagery: An image is draped over the surface so as to give a better sense of place for the scene.


- 23 - Alex Leith | 027986

Figure 11: Showing a view of the final visualisation dataflow (model). This combines the DEM created in the recession process with a rising sea surface and with background imagery.

ResultsThe final recession model was run on a small region of the dataset (see figure 5) as the processing time

is currently quite long and the volume of data required for visualisation large. Recession is shown in

figure 13, at four time steps over 100 years. Inundation is shown in figure 14 both today and in 2100.

These images demonstrate how easy it is to identify predicted changes if it is presented in a form we

are comfortable with. It should be noted that these images show worst case scenarios and should be

taken to be indicative only.

LiDAR Thinning

The LiDAR thinning was run over the study area, which resulted in a data reduction of 33%, bringing

the dataset down from 300000 to 198061 points (see figure 12). Although it was not formally tested,

this resulted in a significant reduction in processing time. Currently the model takes around two hours

to process the small (approximately 1 km x 1 km) area on a computer with a 2.66 GHz quad core

processor, 4 GB of 1066 MHz ram and a NVIDIA GeForce 9800 GTX+ graphics card. The thinning

process also assists in the loading times for the visualisation of the datasets.


Figure 12: Two terrain models (represented by the spherical points) blue points are the original data, while red points are points remaining after thinning.

Buffer

The buffer operator was run on the study area dataset, and for testing purposes was run on the whole

of Tasmania. All areas were buffered adequately, even though there were some limitations and

efficiency problems identified. Figure 10d shows the result of the buffer algorithm on a relatively

complex length of line. One remaining problem is with the large number of redundant points the

operator creates.

Buffers were run for the time periods 25, 50, 75 and 100 years. These correspond to the number of

years from the current year. This time increment is inserted as a parameter to the buffer operator and

the buffer operator uses the time period as a multiplier for the erosion factor, giving the buffer varying

width along the line.

Recession

Recession polygons were created from the buffers. These polygons were used to set the elevation

model heights to 0 in affected areas. These recession buffers are visible in figure 15 and can also be

loaded as a KML (Keyhole Markup Language) file into Google Earth for visualisation (see the web page

<http://home.exetel.com.au/agl/eonproject/>).

Sea Level Rise and Inundation

Sea level rise has been visualised using a simple bathtub model where a flat surface, representing sea

level, can move up and down over time. Inundation can be seen in figures 14 and 16. This model works

adequately but inundates areas which may not be affected in reality, such as low lying inland areas

behind dunes.

- 25 - Alex Leith | 027986



Figure 13: Final Results from the recession model running over the north west area of South Arm. The images are from 2000, 2050, 2075 and 2100 from top to bottom, left to right.

- 27 - Alex Leith | 027986

Figure 14: Showing three inundation scenes, the top is the current elevation model for the area, the centre image is an inundation scenario today and the lower image is inundation of a receded DEM in 2100.

Comparison with Clarence Council (WRL) Report

All the values used in this project compare well to those used in the Clarence Council report (WRL

2008) in that the sea level rise used for their 2100 worst case scenario was 0.9 m while that for this

study was around 1 m. The recession in the WRL report compares very well to the recession buffers

generated in this project (see figure 15). All limits are comparable (see figures 15 and 16); the 2100

high range sea level rise recession lines for the WRL study are slightly further inland than those

generated in this study. This is more likely coincidental as there were simple arbitrary values used for

this area in my study, although it was recognised as a vulnerable shoreline. In the inundation

comparison (see figure 16) there are some slightly larger differences. Inland regions are relatively

similar, although in this project the inundated areas are filled in with blue, while the WRL shaded only

a range of heights (e.g. 2.2–2.6 m for the blue high sea level rise regions (WRL 2008)). In this study

there are a number of houses near the foreshore which were behind the recession lines in the WRL

recession image, but that are not underwater in the inundation image. This shows that this study has

included areas which would be inundated that the WRL (2008) missed.


Figure 15: Recession modelling from this study (left) and the WRL 2007 study (right). Both studies resulted in a very similar set of lines.

- 29 - Alex Leith | 027986

Figure 16: A comparison of inundation modelling from this study (right) and the WRL 2007 study (left). Note that in the right image, blue areas represent a 100 year storm event in 2100, as in the image in the left. Note also that the shaded regions onshore are similar except for where there has been recession modelled. The row of houses nearest the beach on the right appear safe but on the left are under water.

Discussion

Problems and Shortcomings

The major shortfall in this project was the lack of an iterative implementation. An iterative procedure

would have created a unique shoreline after each recession was processed. Sharples (2009) advised that

this was a shortcoming of the WRL report as well. Sharples also stated that since the inundation in the

WRL report (2008) was modelled on the existing shoreline, and as such does not included the receded

area, it would not reflect the true area of inundation (Sharples, C 2009, pers. comm. 18 March).

There is also an issue with the buffer process as it currently runs. The caps at the ends of buffers will

sometimes intrude on areas which will recede less than the capped line. This recedes areas which

would otherwise not recede. Figure 17 illustrates this overlap in buffers. The overlapping areas are not

a problem as such but the green area extending beyond the blue in figure 17 shows how the recession

has affected a headland. This headland would probably not recede in this way. A possible solution to this

issue is that caps at the start and end of lines could be made either optional, or turned off completely.


Figure 17: Illustrating one of the issues with using a buffer process for recession. The caps at the ends of the greens lines are intruding into regions which would likely not be affected by shoreline recession.

This may cause further problems with the small slivers between two differing areas possibly being left

behind and receding at all, leaving a 'jetty' of unaffected land. A more sophisticated buffer operator

could solve this problem.

A final limiting factor of the project was the sheer volume of data points required for the DEM. This

had the effect of scaling down the modelled area so that processing could be completed within a

reasonable time frame. An effective way of partitioning the DEM would be of great utility so that,

when visualising change in the shoreline regions, only affected areas of the DEM should refresh, rather

than the entire region as is currently the case.

Opportunities for Further Study

It is possible and would be useful to wrap the DEM thinning process into a single new operator in

Eonfusion with settings configurable for all parameters. This would enable us to optimise the

algorithm, streamline the process to create a standard form of elevation model compression with

minimal loss of useful data.

It would be advantageous to incorporate better measures of erodible landforms in the form of 2D

polygons or even 3D stratigraphic data for the study areas. Rather than basing the recession rates and

areas solely on the vulnerability line there could be additional data sets limiting the areas prone to

recession. These additional layers could either be incorporated into the model or simply used to refine

the erosion factor as used in the model.

Since the Sharples (2007) coastal vulnerability mapping is consistent over all of Tasmania, and is

nearing completion Australia-wide, this forms an excellent base layer from which to derive erosion

attributes. There is still an opportunity, as better data is made available, to incorporate a coastal

erodibility layer instead of the vulnerability layer. The model has been designed to allow for better data

to be incorporated as it becomes available or is appropriate.

Three things are of high priority for the improvement of the recession model. First, smoothing the

edges of affected areas This is advantageous as the current model doesn't reconcile the shoreline at the

receded areas. In other words, the edge of a region which has receded is followed by a sheer cliff up to

the original surface. To better approximate what would really occur, we could smooth the DEM around

the edges of the affected areas, using an angle of repose which is suited to the dominant landform of

the area.

- 31 - Alex Leith | 027986

The second possible area of improvement lies in achieving an iterative process. This would be achieved

by creating a new line tracing the coastline after each iteration and attaching erosion factors to each

vertex in this new layer. An additional goal could be creating the erosion factor at these points by

implementing GEOMBEST or SCAPE although this would require more input datasets.

A more efficient data storage process for the model, while it is running and also once completed, could

be added. Currently the process must intersect the entire focus area with the buffer regions to find the

areas which will be affected. In order to speed this up, the DEM could be partitioned into areas which

will and will not be affected. This way regions which will not change need not be included in the

calculations and only changed areas would need to change in the visualisation.

The current visualisation holds five DEMs: the original DEM and one for each of years 2025, 2050,

2075 and 2100. Some elevation values remain the same in all DEMs and this duplication of data points

could be removed. One possible method to achieve this would be creating a large buffer first, which

covers the maximum possible affected area, and to cut this section out of the original DEM. This way

we can have one static model, for the hills and inland regions, and one changing model, for the beaches

and other receding regions.


ConclusionThis research has reviewed current literature on sea level rise, coastal recession and modelling and

visualisation in 4D GIS. Eonfusion has been used to model and visualise complex data in four

dimensions. Current values for predicted sea level rise due to climate change, inundation events and

for rates of recession have been collected. These values were used for input into a coastal recession

model which was implemented in Eonfusion, with the use of Eonfusion's new User Coding

Environment.

This model of coastal recession, sea level rise and inundation events has been visualised in four

dimensions, and video is available online. The results of this research compare well to previous and

current research. It has been shown that this research has advantages in the modelling of inundation

events on receded shorelines over other current research.

The research has shown that integrating both sea level rise and shoreline recession due to climate

change and visualising both provides an important understanding of coastal vulnerabilities. Eonfusion

has proven to be a powerful tool which integrates both the modelling and visualisation of complex

datasets in three dimensions through time. The ability to visualise the probable impacts of climate

change on coastal communities and ecosystems will prove important for communities, policy makers

and researchers into the future. Visualising such complex systems in three dimensions and as they

change through time affords a unique insight into the processes and their consequences.

- 33 - Alex Leith | 027986

ReferencesBrown, I. et al., 2006. Dynamic simulation and visualisation of coastal erosion. Computers, Environment

and Urban Systems, 30(6), 840-860.

Bruun, P., 1988. The Bruun Rule of Erosion by Sea-Level Rise - a Discussion on Large-Scale Two-Dimensional and Three-Dimensional Uses. Coastal Education and Research Foundation, 4(4), 627-648.

Church, J.A. & White, N.J., 2006. A 20th century acceleration in global sea-level rise. Available at: http://www.agu.org/pubs/crossref/2006/2005GL024826.shtml [Accessed March 11, 2009].

Church, J.A. et al., 2008. Sea-level rise and the vulnerability of coastal environments. Transitions, Pathways Towards Sustainable Urban Development in Australia (uncorrected proof).

Cooper, J.A.G. & Pilkey, O.H., 2004. Sea-level rise and shoreline retreat: time to abandon the Bruun Rule. Global and Planetary Change [Global Planet. Change]. Vol. 43, 43(3-4), 157-171.

Cowell, P.J., Roy, P.S. & Jones, R.A., 1992. Shoreface translation model: computer simulation of coastal-sand-body response to sea level rise. Mathematics and computers in simulation, 33(5-6), 603-608.

Goralwalla, I.A., Özsu, M.T. & Szafron, D., 1998. An Object-Oriented Framework for Temporal Data Models. In Temporal Databases: Research and Practice. pp. 347-350. Available at: [Accessed May 5, 2009].

Hazelton, N., Leahy, F. & Williamson, I., 1990. On the Design of Temporally Referenced, 3D Geographical Information SystemsL Development of Four-Dimensional GIS. GIS/LIS Conference 1990 Anaheim, California, USA.

Hennecke, W.G., 2004. GIS Modelling of Sea-Level Rise Induced Shoreline Changes Inside Coastal Re-Rntrants – Two Examples from Southeastern Australia. Natural Hazards, 31(1), 253-276.


Höllerer, T., Kuchera-Morin, J. & Amatriain, X., 2007. The allosphere: A large-scale immersive surround-view instrument. In ACM International Conference Proceeding Series. Available at: [Accessed May 5, 2009].

IPCC, 2007. Fourth Assessment Report (AR4) Chapter 10, Intergovernmental Panel on Climate Change.

Li, X. & Kraak, M., 2008. The Time Wave. A New Method of Visual Exploration of Geo-data in Timespace. Cartographic Journal, The, 45, 193-200.

Mandlburger, G. & Briese, C., 2007. Using Airborne Laser Scanning for Improved Hydraulic Models. International Congress on Modeling and Simulation.

McInnes, K. et al., 2007. Assessing the Impact of Climate Change on Storm Surges in Southern Australia. CSIRO.

Poulter, B. & Halpin, P.N., 2008. Raster modelling of coastal flooding from sea-level rise. Int. J. Geogr. Inf. Sci., 22(2), 167-182.

Rahmstorf, S., 2007. A Semi-Empirical Approach to Projecting Future Sea-Level Rise. Science, 315(5810), 368-370.

Sharples, C., 2007. Indicative Mapping of Tasmanian Coastal Vulnerability to Climate Change and Sea Level Rise: Explanatory Report (version 2)., Department of Primary Industries, Water and Enviroment, Hobart, Tasmania.

Stolper, D., List, J.H. & Thieler, E.R., 2005. Simulating the evolution of coastal morphology and stratigraphy with a new morphological-behaviour model (GEOMBEST). Marine Geology, 218(1-4), 17-36.

Woth, K., Weisse, R. & von Storch, H., 2006. Climate change and North Sea storm surge extremes: an ensemble study of storm surge extremes expected in a changed climate projected by four different regional climate models. Ocean Dynamics, 56(1), 3-15.

WRL, 2008. Coastal Processes, Coastal Hazards, Climate Change and Adaptive Responses for Preparation of a Coastal Management strategy for Clarence City, Tasmania, Technical Report 2008/04.

- 35 - Alex Leith | 027986

Appendices

Appendix 1: Krill Demo

This data set was sent to the author by Dr Jon Osborn at the University of Tasmania and is the result of

some work involving measuring krill with close range photogrammetric techniques in a fish tank at the

Australian Antarctic Division. These krill were photographed with a stereo video camera and their

locations in X,Y and Z recorded at up to 260 instances in time. These data were provided in the form

of a text file and were loaded into Eonfusion with the tabular text operator. It was a simple operation

to assign a time parameter at each epoch, create a point for each instance and aggregate all points

belonging to an individual krill. This enabled the data to be viewed in three dimensions over time, as

can be seen interactively on the web page <http://home.exetel.com.au/agl/eonproject>and in

figures 18 and 19. Being able to navigate the data set in three dimensions, to isolate periods of time,

view each epoch individually or at arbitrary lengths can afford a way to identify interactions between

individuals which would be very difficult to observe if working with a tabular data set or a 2D or even

3D map.


Figure 18:The figure on the right shows three epochs, this way as we move the time slider (at the bottom of the figure) we can watch the krills' movements and interactions. Note the error ellipsoids representing the quality of the coordinates for the krill.

http://home.exetel.com.au/agl/eonproject

- 37 - Alex Leith | 027986

Figure 19: This figure shows the entire data set of krill locations, at all epochs. Each individual is uniquely coloured and when in Eonfusion we can dynamically move through the scene.

Appendix 2: Sample Code: Buffer Operatorusing System;using System.Collections.Generic;using System.Linq;using System.Text;using Myriax.API.Data;using Myriax.API.UI;using Myriax.API.Binding;

namespace BufferLine{ [UIBinding(PropertyName = "Line vector set group",DefaultValue="Vectors")] public class LineInput : VectorSetGroup<LineInput.MyVectorSet2D, LineInput.MyVectorSet1D, LineInput.MyVectorSet0D, LineInput.Vertex> { //[Myriax.API.Binding.ListBinding(PropertyName = "Attribute Group", PropertyDescription = "The Line Attibute Group", DefaultValue = "Vectors.Vertices")] public abstract class Vertex : TableRow { [ListBinding(PropertyName = "Line X", PropertyDescription = "X coordinate", DefaultValue = "X", BindUsingUI = true)] public abstract double Easting { get; set; }

[ListBinding(PropertyName = "Line Y", PropertyDescription = "Y coordinate", DefaultValue = "Y", BindUsingUI = true)] public abstract double Northing { get; set; }

} public class MyVectorSet0D : VectorSetGroup<LineInput.MyVectorSet2D, LineInput.MyVectorSet1D, LineInput.MyVectorSet0D, LineInput.Vertex>.VectorSet0DBase { } public class MyVectorSet1D : VectorSetGroup<LineInput.MyVectorSet2D, LineInput.MyVectorSet1D, LineInput.MyVectorSet0D, LineInput.Vertex>.VectorSet1DBase<MyVectorSet1D.My1DFeature, MyVectorSet1D.My1DPrimitive> { public abstract class My1DFeature : MyVectorSet1D.Feature { [ListBinding(PropertyName = "Erosion Factor", PropertyDescription = "A value of erodibility", DefaultValue = "Erosion_Fac", BindUsingUI = true)] public abstract double Radius { get; set; }

} public abstract class My1DPrimitive : MyVectorSet1D.Primitive { } } public class MyVectorSet2D : VectorSetGroup<LineInput.MyVectorSet2D, LineInput.MyVectorSet1D, LineInput.MyVectorSet0D, LineInput.Vertex>.VectorSet2DBase<MyVectorSet2D.My2DFeature, MyVectorSet2D.My2DPrimitive> { public abstract class My2DFeature : MyVectorSet2D.Feature {// [ListBinding(DefaultValue = "Link to Line")] public abstract MyVectorSet1D.My1DFeature LinkToLine { get; set; } }

public abstract class My2DPrimitive : MyVectorSet2D.Primitive { [ListBinding(DefaultValue = "Vulnerable", CreateIfMissing = true)] public abstract bool Vulnerable { get; set; } } } }

public class Buffer_Line : Myriax.API.IAddInOperatorContract { CompositeNamedItemProperty<LineInput> LineBindingProperty = new CompositeNamedItemProperty<LineInput> { BindingSocketIndex = 0 };

//Add triangle manages the 'sidedness' of a triangle (a component of a surface). This way all triangles are up side up! private void AddTriangle(LineInput.MyVectorSet2D.Vector2DListBuilder builder, LineInput.Vertex a, LineInput.Vertex b, LineInput.Vertex c) {


double ux = b.Easting - a.Easting; double uy = b.Northing - a.Northing; double vx = c.Easting - a.Easting; double vy = c.Northing - a.Northing;

if (ux * vy - vx * uy > 0) { builder.UseVertices(a, b, c); } else { builder.UseVertices(a, c, b); } }

public Dataset HandleCreateDataset(DatasetCollection inputDatasets) { //Give the line vectorset a handle, so we can use it. var lineVectorSetGroup = inputDatasets.BindNamedItem(LineBindingProperty);

//A link to the data on the line input (used for connecting to the erosion factor on the line). var linkToLine = lineVectorSetGroup.VectorSet2D.FeatureTable.CreateSingleLinkList("Link to Line", lineVectorSetGroup.VectorSet1D.FeatureTable); lineVectorSetGroup.VectorSet2D.FeatureTable.SetListBinding("LinkToLine", linkToLine);

// below structure courtesy of Brett. // We want to buffer every feature, so iterate through that table: foreach (var feature in lineVectorSetGroup.VectorSet1D.FeatureTable.Rows) { //This sets up the buffer radius, or offset. double offset = multiplier * (feature.Radius / 100 );

//**This is a surface feature and builder, which will build a feature for the buffer. // Building a 2D feature, as a list of triangle primitives var feature2D = lineVectorSetGroup.VectorSet2D.FeatureTable.AllocateOne(); feature2D.LinkToLine = feature; // Create a "feature builder" var featureBuilder2D = lineVectorSetGroup.VectorSet2D.BuildFeaturePartFromVertexList(feature2D);

// Make sure that this feature has at least one primitive. // It probably does, but need to make sure. if (feature.Primitives.Count > 0) { // Pick out any old primitive that the feature uses, as a starting point: var primitive = feature.Primitives[0];

// Get a handle that points to this primitive: var lineHandle = primitive.GetPrimitiveHandle();

// Initialize a local variable for keeping track of the primitive we were on last time, // so that we know when we've reached the end of the line. var previousPrimitive = lineVectorSetGroup.VectorSet1D.PrimitiveTable.NullRow;

// Iterate along the line until we hit one of our exit conditions. Either no movement or hitting world vertex. while ((previousPrimitive != lineHandle.Primitive) && (lineHandle.Dest.RowIndex != 0)) { previousPrimitive = lineHandle.Primitive; lineHandle.SwapVertex().FlipOver(); }

// If we iterated to a primitive connecting to the world vertex, flip back onto the line: if (lineHandle.Dest.RowIndex == 0) { lineHandle.SwapVertex(); }

// Ok, now our primitiveHandle is at one end of the line and pointing along the line. // We can do what we actually want to do with it now.

- 39 - Alex Leith | 027986

previousPrimitive = lineVectorSetGroup.VectorSet1D.PrimitiveTable.NullRow;

//********************************* //**Create a cap at the front.** //*********************************

//Select vertices to buffer. var currentVertex = lineHandle.Orig; var nextVertex = lineHandle.Dest; //Create some spare vertices. var newVertexCollection = lineVectorSetGroup.VertexTable.AllocateMany(3); var prevVertexCollection = newVertexCollection;

//find delta east and north and the euclidean distance. double dX = currentVertex.Easting - nextVertex.Easting; double dY = currentVertex.Northing - nextVertex.Northing; //double lastDX = dX, lastDY = dY; double hyp = Math.Sqrt(dX * dX + dY * dY); //double lastHyp = hyp; //scale delta X and Y's. dX = (dX / hyp) * offset; dY = (dY / hyp) * offset;

//Create the point extended back from the line. newVertexCollection[2].Easting = currentVertex.Easting + dX; newVertexCollection[2].Northing = currentVertex.Northing + dY;

//Create one point between this and each of the two perpendicular points (can easily be modified to make more). double theta = Math.Atan2(dX, dY); newVertexCollection[0].Easting = currentVertex.Easting + offset * Math.Sin(theta + Math.PI / 4); newVertexCollection[0].Northing = currentVertex.Northing + offset * Math.Cos(theta + Math.PI / 4);

newVertexCollection[1].Easting = currentVertex.Easting + offset * Math.Sin(theta - Math.PI / 4); newVertexCollection[1].Northing = currentVertex.Northing + offset * Math.Cos(theta - Math.PI / 4);

//create some triangles AddTriangle(featureBuilder2D, newVertexCollection[0], newVertexCollection[2], currentVertex); AddTriangle(featureBuilder2D, newVertexCollection[1], newVertexCollection[2], currentVertex);

// **Move along the line** // Iterate along the line again until we hit one of our exit conditions, at the OTHER end of the line: while ((previousPrimitive != lineHandle.Primitive) && (lineHandle.Dest.RowIndex != 0)) {

//Select vertices to buffer. currentVertex = lineHandle.Orig; nextVertex = lineHandle.Dest; //Create some spare vertices. Assign the last lot of vertices to the var: prevVertexCollection prevVertexCollection = newVertexCollection; newVertexCollection = lineVectorSetGroup.VertexTable.AllocateMany(4);

//find delta east and north and the euclidean distance. dX = currentVertex.Easting - nextVertex.Easting; dY = currentVertex.Northing - nextVertex.Northing; hyp = Math.Sqrt(dX * dX + dY * dY);

//Create a unit vector, scaled by the offset(buffer) distance. double dXu = (dX / hyp) * offset; double dYu = (dY / hyp) * offset;

//buffer the first point newVertexCollection[2].Easting = currentVertex.Easting + dYu; newVertexCollection[2].Northing = currentVertex.Northing - dXu; newVertexCollection[3].Easting = currentVertex.Easting - dYu; newVertexCollection[3].Northing = currentVertex.Northing + dXu; //buffer the second point newVertexCollection[0].Easting = nextVertex.Easting + dYu;


newVertexCollection[0].Northing = nextVertex.Northing - dXu; newVertexCollection[1].Easting = nextVertex.Easting - dYu; newVertexCollection[1].Northing = nextVertex.Northing + dXu; //** //TODO: attempt at putting the wedges in. //**

//build the surface along the line AddTriangle(featureBuilder2D, prevVertexCollection[0], newVertexCollection[2], currentVertex); AddTriangle(featureBuilder2D, prevVertexCollection[1], newVertexCollection[3], currentVertex); AddTriangle(featureBuilder2D, newVertexCollection[1], newVertexCollection[0], newVertexCollection[2]); AddTriangle(featureBuilder2D, newVertexCollection[1], newVertexCollection[3], newVertexCollection[2]);

previousPrimitive = lineHandle.Primitive; lineHandle.SwapVertex().FlipOver(); }

//********************************* //**Create a cap at the back.** //*********************************

//Select vertices to buffer. currentVertex = lineHandle.Orig; nextVertex = lineHandle.Dest; //Create some spare vertices prevVertexCollection = newVertexCollection; newVertexCollection = lineVectorSetGroup.VertexTable.AllocateMany(3);

//find delta east and north and the euclidean distance. dX = currentVertex.Easting - nextVertex.Easting; dY = currentVertex.Northing - nextVertex.Northing; hyp = Math.Sqrt(dX * dX + dY * dY); //scale delta X and Y's. dX = +(dX / hyp) * offset; dY = +(dY / hyp) * offset;

//Create the point extended back from the line. newVertexCollection[2].Easting = currentVertex.Easting + dX; newVertexCollection[2].Northing = currentVertex.Northing + dY; //Create one point between this and each of the two perpendicular points (can easily be modified to make more. theta = Math.Atan2(dX, dY); newVertexCollection[0].Easting = currentVertex.Easting + offset * Math.Sin(theta + Math.PI / 4); newVertexCollection[0].Northing = currentVertex.Northing + offset * Math.Cos(theta + Math.PI / 4);

newVertexCollection[1].Easting = currentVertex.Easting + offset * Math.Sin(theta - Math.PI / 4); newVertexCollection[1].Northing = currentVertex.Northing + offset * Math.Cos(theta - Math.PI / 4);

//create some triangles for the end cap AddTriangle(featureBuilder2D, newVertexCollection[0], newVertexCollection[2], currentVertex); AddTriangle(featureBuilder2D, newVertexCollection[1], newVertexCollection[2], currentVertex); AddTriangle(featureBuilder2D, prevVertexCollection[0], newVertexCollection[1], currentVertex); AddTriangle(featureBuilder2D, prevVertexCollection[1], newVertexCollection[0], currentVertex);

} } return inputDatasets[0]; } //Get the required offset value (for the buffer). DoubleProperty multiplier = new DoubleProperty(); #region Authoring information

public string ContextMenuCategory { get { return "add-in"; } }

- 41 - Alex Leith | 027986

public int InputSocketCount { get { return 1; } }

public string Author { get { return "Alex Leith, UTAS, Modified after and with assistance of Brett Muir, Myriax Software"; } }

public string Description { get { return "Builds a simple buffer around a line. There are redundant points and triangles created but works well enough."; } }

public string Version { get { return "1.0"; } }

#endregion }}


Appendix 3: Shoreline vulnerability (erosion factor) maps.

- 43 - Alex Leith | 027986


Thanks for all the fish.

Documents

4D Geographic Information Systems - Shoreline Recession in ...home.exetel.com.au/agl/files/Eon_Project_FINAL.pdfusing the open source GIS software called GRASS (geographic resource