Driving Google Earth from Fortran
Gen-Tao Chianga, Toby O.H. Whiteb, Martin T. Dovea,b
aNational
Institute for Environmental eScience, Downing Street, Cambridge, CB2 3EQ, UK
of Earth Sciences, Downing Street, Cambridge, CB2 3EQ, UK
bDepartment
Abstract
Google Earth provides a radical improvement over previous generations of geospatial visualization
applications. By offering a well-documented input data format, KML, it enables researchers to
visualize existing data from multiple sources, as well as data they might produce themselves, on a
common geographical canvas. However, this requires having data available in KML. Many
computational programs in use across the geosciences are written in Fortran; and many researchers
are most comfortable writing in Fortran. Building on earlier work where we constructed a general
XML Fortran library, we have written a KML output library which enables the direct output from
Fortran programs of scientific data in KML format, without post-processing, and requiring no
knowledge of KML on the user’s part.
1. Introduction
Visualization of data in the geosciences provides
particular challenges not encountered in other
sciences. The need to provide geographical context to
data - to place it at a particular point on a map - has
resulted in a multiplicity of geospatial visualization
packages[1].
The public launch of Google Earth (GE) in 2005,
revolutionized the field. Although its data analysis
capabilities are underpowered compared to more
traditional Geographical Information System (GIS)
packages, it is significantly simpler to use and more
richly interactive than previous geobrowsers. For
simple geospatial exploration of data it is
unparalleled in ease of use. Equally importantly, it is
free of cost, bringing access to high quality
geographical imagery within reach of any
geoscientist equipped with a computer and an
internet connection.
A particularly important part of GE's appeal is the
Keyhole Markup Language (KML)[2]. This is a
format in which users can provide their own data in
order that it can be visualized within the GE
application. KML also expresses a rich programming
interface for building complex domain-specific
applications on top of GE. This extensibility has
proved invaluable to the geoscientific world - a
measure of its importance is the fact that there were
at least 19 separate presentations devoted to
exploring the uses of GE/KML at the Fall 2006
Meeting of the American Geophysical Union[3].
However, although there is much to be gained
from fully exploiting the complexity of KML, a large
part of the appeal of GE is the ability to incorporate
very simple data - points, lines, and polygons - into
GE and see them in a geographical context. Simply
being able to put data onto such a richly interactive
map is valuable in itself.
Of perhaps greater importance, GE provides a
single platform for the visualization of data from
entirely disparate sources. As long as data is
available in a KML format, its origin is irrelevant,
and it may be viewed within GE - this enormously
aids cross-disciplinary collaborations; earth system
scientists from very different backgrounds can
quickly exchange and visualize each other's data on a
common canvas, without having to learn new tools
for exploring the information.
Thus KML provides a clear example of eScience
in action - using advances from the field of
information management to enable collaboration
through accessible scientific visualization.
However, it is still necessary to produce the
KML that GE requires. This task, although not taxing
for the well-educated programmer familiar with
XML, is not entirely trivial. KML is another data
format whose intricacies one must learn, and an overworked scientist, not expert in computers, may feel
they have better things to do.
The history of computational geoscience has
resulted in a situation where large numbers of
scientific programs, which output data of geospatial
interest, are written in Fortran. As a result, many
scientists only understand that one computer
language. This means that much data of geoscientific
interest is being produced by Fortran programs - and
many scientists who wish to write short analysis or
data transformation programs will choose to do so in
Fortran. Unfortunately though, producing XML from
Fortran is not generally an easy task.
Thus the potential eScientific gains of KML use
have not yet been brought to the doorstep of the
average computational geoscientist; in this paper we
describe our efforts to bridge this gap.
We perceived the need for a Fortran library which
enables the easy generation of KML, to be used both
in existing Fortran programs, and to be used in new
programs written by scientists who know only
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Placemark>
<Point>
<coordinates>-122.0822,37.4222</coordinates>
</Point>
</Placemark>
</kml>
Figure 1: Minimal KML document to produce a single placemarker. In bold are the only quantities
important to a typical scientist - the rest is apparently unnecessary verbiage.
Fortran. One of us (TOHW) had previously written a
generic Fortran XML library, FoX[4], motivated by
the requirement to produce CML (Chemical Markup
Language) data from existing Fortran codes. We have
built upon FoX an additional output layer, WKML
(because it Writes KML), which allows the direct
output of KML from Fortran.
This work is therefore of direct significance for
eScience. The KML platform itself, though not
necessarily designed as such, may aptly be
characterized as eScientific in its features, both in
visualizing scientific data, and in enabling scientific
collaboration by providing a common encoding for
geobrowsing data, and a number of common
interfaces for visualizing such data. By allowing the
Fortran-literate geoscientist to wield some of the
power inherent in KML we are contributing to the
working scientist’s eScience toolkit.
2. KML
KML is an XML language for entering information
into GE. As such, it has two main strands. Part of
KML is concerned with representing geospatial data,
while part of it is concerned with how that data
should be displayed within Google Earth. It contains,
therefore, a mixture of semantic and presentation
layers.
The semantic layer, which consists of a set of tags
for marking up geospatial primitives (two- and threedimensional specifications for points, lines, and
<Point>
A single point
<LineString> A path (a series of
connected points)
<Polygon>
A region defined by an
outer boundary
consisting of a closed
line, and optionally
multiple inner
boundaries defining
excluded holes.
Table 1: KML Geometric Primitives. In each case the
coordinates used may have altitudes specified, allowing
three-dimensional objects to be specified.
polygons), is essentially identical to the portion of
the Geography Markup Language (GML)[5] which
encodes the same information. Table 1 describes
these geometric primitives.
In addition to GE, at least two other geobrowsing
systems (NASA WorldWind[6] and ESRI ArcGIS
Explorer[7]) now understand portions of the KML
language. Furthermore, KML is currently being
considered by the Open Geospatial Consortium
(OGC)[8] for standardization.
These factors mean that KML is the most
immediately accessible and widely spread format for
encoding geospatial information. Free (both in
monetary and licensing terms) and commerciallysupported client viewers are available for all major
platforms. In particular, GE allows developers to
build large and complex domain-specific applications
with GE as the geobrowsing component.
The KML language itself is well-specified, and
extremely well-documented, and it offers a wide
array of
features to the seasoned developer.
However, to a scientist who programs only out of
immediate necessity, and who is mostly familiar with
Fortran, it is not immediately accessible. The
simplest obvious task - placing a visible point on the
globe, given its latitude and longitude - although in
principle requiring nothing more than those two
numbers, in practice requires about 150 characters of
boilerplate (see Figure 1) all of which has its
purpose, but which obscures and hinders the scientist
who merely wants to visualize a simple location.
To a developer familiar with XML, it is easy to
generate these 150 characters quickly and correctly.
However, to a user familiar with, at best, a bit of
HTML, and possibly unfamiliar with markup
languages at all, it is not clear what portions of the
markup are significant, and how. If mistakes are
made in the output, it is very difficult to isolate and
correct them. Furthermore, the easiest way to
produce XML will be by a series of PRINT
statements; but these are extremely fragile. A small
typo resulting in ill-formed XML will not make the
code fail; it will compile and run correctly, but the
XML will not be usable. Furthermore, it is easy to
destroy the larger structure of the XML document by
exercising different code paths, and, for example,
omitting to PRINT the closing tag, with the same
results.
Making XML output accessible to a nonspecialist therefore requires providing layers of
abstraction to ensure that, at the very least, such
trivial syntax errors are impossible, and ideally, that
the code developer need never interact with the
XML at all. Rather they should specify what
information they want to output, and the XML
serialization should be automatically generated.
In order to make GE accessible as a visualization
platform to such scientists, it was necessary to
identify the key concepts that geospatial scientists
wanted to display, and provide a way for them to
quickly generate KML files which did so. We had
prior experience of building a CML-specific library
within FoX. So, to this end, we wrote WKML, which
has a series of API calls which allow the output of
easily constructed geometric primitives, which are
those most frequently desired by geospatial
scientists. The API has been designed so that it can
be used with the minimum of complication, so that
simple data can be visualized in a quick and dirty
fashion - but with enough control over the output that
more visually attractive output can also be created.
It should be noted, though, that WKML is in no
way intended to allow the programmer access to the
full power of KML. KML is a large and complex
language, and no abstracted API can hope to sensibly
reflect its full power. Furthermore, building the sort
of complicated application that requires the full
gamut of KML options is a task for which Fortran is
very badly suited.
WKML is specifically designed for use both in
existing Fortran programs, where quick and easy
KML output allows users to immediately visualize
generated data with the minimum of post-processing
fuss, and for use by scientific programmers for whom
Fortran is their primary or favoured language. In
almost all other circumstances another more flexible
language would be a much wiser choice for
manipulation of KML documents.
3. WKML
3.1 Fortran libraries
Writing a library in Fortran presents certain
difficulties not encountered in other languages. This
is partly due to Fortran’s heritage, which makes
expressing some tasks rather more laborious than it
ought to be. However, there are some other
peculiarities. Fortran codes are used on multiple
hardware/OS combinations, with over 10 different
compilers in common use. Although Fortran is
limited in some ways, its cross-platform portability is
a strength which any library must maintain - losing it
severely compromises the utility of a library.
In some cases, tasks might be more easily
accomplished in another language, or indeed a
library implementing the required functionality might
already exist. However, in practice, cross-language
linking with Fortran is a complex business; and the
number of different Fortran compilers in use means
that the cost of doing so portably is prohibitive.
An alternative approach to the problems we have
described is to write scripts in a more modern
language, to transform existing output from Fortran
programs into KML. In some ways this would be
distinctly easier than writing a Fortran KML library.
However, this suffers two major disadvantages.
Firstly, someone still has to write those scripts. If
a scientist is working in a problem domain where
such scripts have been written, then this may well be
a better solution - however, when this is not the case,
the scientist is more likely to understand Fortran than
a suitable scripting language.
Secondly, it adds another point of failure, and
imposes an additional cost on any users other than
the original developer, who now need to know not
only how to operate the Fortran program itself, but
also how to use an additional set of postprocessing
scripts, which may not be documented, and will have
new modes of failure.
For both these reasons, we have found that direct
KML output from Fortran is far preferable as a
general strategy.
3.2 WKML philosophy
WKML allows the creation of KML documents
containing elements representing geometric
primitives, which make up the entities which are of
most use to a scientist wishing to quickly visualize
data.
A very important point to note is that WKML has
been designed with ease of use as a primary goal.
Thus when designing the API to which users have
access, the focus has not been to allow users to
output KML of a certain sort - rather it has been to
allow users to express the sort of entities that they
want to visualize, in a way as natural to them as
possible - and then have WKML seamlessly translate
these entities into KML, without having the user
need to know about the details of the KML produced.
The API was designed as a direct result of its use in
relevant scientific projects, some of which are
described in section 5.
The primitive items which scientists, in our
experience, wish to visualize may be roughly
construed as 0-, 1-, 2- and 3- dimensional data.
• Individual points (possibly with altitude)
• Paths - series of connected points (possibly
with altitude), potentially open or closed.
• Regions - boundaries defined by closed lines,
and with additional possible inner boundaries.
• Fields of data - z-values on a two-dimensional
grid, which may be represented either by height or
by isocontours.
The first three items can be represented by KML
primitives (as shown in Table 1) and the job of the
WKML library on being called is to translate a set of
coordinates to the appropriate KML output.
For the final item, representing three dimensional
data, there are no suitable native KML structures, but
a display can be built using the same primitives as
before. Of course, the library must then translate
between the user’s view of the data (a twodimensional array of data on a grid), and the KML
WKML call
KML objects generated
kmlCreatePoints
<Point>
kmlCreateLine
<LineString> (if open)
<Polygon> (if closed), with no inner boundaries
kmlCreatePolygon
<Polygon> with optional inner boundaries
kmlCreateCells
<Polygon>
kmlCreateContours
<LineString>
<Polygon>
Table 2: KML object generated by each WKML call.
representation - a series of points, lines and contours
defined upon coordinates which are derivative
quantities of the user’s data.
However, from the perspective of the user, the
additional complication is immaterial - there is
simply zero-, one-, two-, or three-dimensional data to
be visualized - the user doesn’t want to care about
anything more than feeding in the data, and then
using the generated KML.
This is illustrated in Table 2, which lists some of
the user-accessible WKML API calls, and the
corresponding KML objects which are produced. It
can be seen that there is not a one-to-one
correspondence, even in the case of the simpler
functions. Here we describe only a simplified version
of the API. The full documentation may be found on
the project’s website at:
http://www.niees.ac.uk/wkml/
3.4 Output of points
Points can be output, singly or multiply, using the
WKML call:
call kmlCreatePoints(kf, points)
Since the calling program may have data
available in various structures, points may be
specified in various forms (single or double precision
floats, as separate latitude and longitude, or as a
width-2 array; perhaps with altitude data included as
well). Subroutine overloading is used to ensure that
all this happens through a single interface, so the user
need remember as little as possible.
The call above will produce simple placemarkers,
which may be all the user needs. However, various
options are available to allow styling the points that
are produced in case more complexity is required.
3.3 File management
3.5 Output of paths
In order to allow KML output, the user needs to
open and close a file - to ensure that the file is wellformed XML, this is done through an opaque
interface:
type(xmlf_t) :: kf
call kmlBeginFile(kf,‘out.kml’,-1)
A path (a series of connected points) can be output in
a very similar way:
call kmlCreateLine(kf, points)
An XML file handle must be declared, and then a file
attached to it.* Every call thereafter to a WKML
subroutine must reference the file handle - thus
multiple KML files may be written to from the same
program.
This call takes care of opening the file, and
adding any standard content (an XML declaration, a
KML namespace declaration, etc.)
Similarly, the file must be closed once complete:
call kmlFinishFile(kf)
*
Because of Fortran’s peculiarities in file handling, it is
necessary to assign a unique integer to every open file. This
must not coincide with any other files the program may
open, so must be under the user’s control. It is specified by
the third argument to kmlBeginFile, and a value of -1
asks WKML to pick a currently unused number.
This subroutine interface is very similar to
kmlCreatePoints, but the generated KML
displays a connected line. There is an optional
Boolean argument, closed, which determines
whether the points should form a closed loop or
not.
Again, when used as above a very simple default
line will be produced. However, multiple styling
options are available if the user requires it.
3.6 Output of regions
The API for outputting regions is slightly more
complex since multiple inner boundaries may be
specified. Therefore several subroutine calls may be
necessary:
call kmlStartRegion(kf, points)
call kmlAddInnerBoundary(kf, in1)
call kmlAddInnerBoundary(kf, in2)
call kmlEndRegion(kf)
The initial kmlCreatePolygon call has an
interface very similar to kmlCreateLine, again
with styling options. The later calls to create the
inner boundaries (the excluded regions) take only
lists of points (in1, in2). Appropriate checks are
made to ensure that inner boundaries are only added
where appropriate.
3.7 Output of 2D field data
2D field data consists of a series of z values across a
grid whose x and y values we know. WKML only
supports structured data currently, where the grid is
topologically rectilinear. WKML offers two ways to
display this data - representing the z value either by
height or by colour.
3.7.1 By height
In the first case, a three-dimensional structure is
generated whose height varies with z. This is
particularly useful for displaying remodelled terrain,
where the z value is in fact altitude data - but is often
of use for other data. To produce this KML output,
the following call is used:
call kmlCreateCells(kf, x, y, z)
Clearly the z values must be supplied (which will be
a two-dimensional array), so also must the latitude
and longitude values of the grid. If the grid is
rectilinear and aligned with lines of latitude and
longitude, then x and y need only be one-dimensional
arrays - in the case of a more complex grid, each
must be a two-dimensional array.
This will produce a series of quadrilateral
polygons, whose vertices are at the grid points at the
altitude of the value of z at that grid point (see
section 5.2 for an illustration). Unless otherwise
specified, a default styling will be used, however,
again, various options can be used to control the
visual styling if required.
3.7.2 By contour
In the second case, the z-values are analysed to
calculate iso-lines, and then the regions between the
contour lines are identified according to the z-values
contained therein. KML to display these iso-lines and
contour regions is then generated.
The algorithm for this is briefly described in the
next section, but is largely unimportant from the
user’s perspective. To produce this KML output, the
following call is used:
call kmlCreateContours(kf, x, y, z)
Since the input data is identical, the interface is very
similar to that of kmlCreateCells. However, in
this case, contour levels must also be chosen. If
unspecified, defaults will be used; otherwise contour
lavels may be specified either by number (for
example that there be 10 levels between the
maximum and minimum z), or by explicit value.
In order to allow for displaying only regions of
interest (for example, when representing sea surface
temperature, contours should not be drawn across
land), areas of the field which should be excluded
can be assigned an arbitrarily high z value, and this
value passed to kmlCreateContours - the
calculated isocontours and contour regions will then
not pass across these regions.
The output of this function is, by default both isolines and contour regions, all of which are distinct
entities in KML (and thus may be individually
manipulated in GE) - but if only iso-lines, or only
contour regions are desired, the output of one can be
switched off.
Again, default styling will be chosen in the
absence of further information, but various options
are available to control visual display.
3.8 Styling and other calls
For the above subroutine calls, we have mentioned
that there are facilities for applying display styles to
the generated KML. In this abbreviated description
of the API, we shall not explore the styling
subroutines further, and refer the interested reader to
the full WKML documentation.
There are also a number of less frequently-used
subroutines which expose more arcane corners of
KML. Again, we note that they are described in the
full documentation.
4. Contour plots
One of the most frequent requests we had from
geoscientists was the ability to quickly visualize a
two-dimensional field of data as contours, on GE.
However, KML offers no facilities for this; it only
knows about points, lines, or polygons (or overlaid
images). In order to produce any display within GE,
the data producer must construct their display from
these primitives.
In order to produce a two-dimensional plot of
data, there are in principle several avenues available.
Where the data can be usefully visualized as altitude,
then kmlCreateCells can be used. However,
more often it is useful to use familiar twodimensional coloured contour plots, superimposed
upon the landscape. Accomplishing this is more
difficult.
The most obvious way is to take the existing 2D
data, feed it to a graphing program which can
produce contour plots in some commonly-used
graphics format (for example JPEG) and then
construct a KML document with a reference to the
generated JPEG.
This was not an option for several reasons.
Firstly, that requires a post-processing step which is
one of the things we have been trying to avoid. It is
not possible to produce the JPEG directly from
Fortran - since standard Fortran offers no raw binary
I/O it is impossible to generate any useful image
formats directly. Furthermore, this would mean
dealing with two files, not just one. This means either
hosting the JPEG somewhere network-accessible
(another post-processing step) or gzip-ing the KML
file together with the JPEG to produce a .kmz file but again, this is either an additional post-processing
step, or must be done by the library - but again, since
The result of passing a 2-D field of data, plus the
locations of the grid points, through this algorithm is
• A list of lines, both open and closed, indexed
by contour value.
• A list of polygons (with outer and inner
boundaries) indexed by the range of z values they
contain.
WKML will then write these lines or polygons in
KML form to the output file. An example is shown in
Figure 2, demonstrating contour lines and regions
generated on a a complex grid, with the default
styling options.
5. Use cases
Figure 2: Contour lines and regions calculated across a
field defined on a non-rectangular grid.
Fortran has no binary I/O, gzip files cannot be
produced.
This solution is also far from ideal since in
converting the data to an image, all the information
about the data values is lost, and only the image
colours remain.
A second option is to follow the lead of
kmlCreateCells, but ignore the altitude, and
simply colour each polygon according to z value.
This does work, but can result in enormous KML
files. Each polygon requires about 300 bytes, so that
a 500x500-point field of data, by no means
unreasonably large, requires around 75Mb of KML.
As the size of datasets increases, filesize becomes
untenably large - it takes several minutes just to load
a 75Mb file into GE.
The final option is to let the library translate the
2D field of data directly into lines and polygons, and
then output those. This was technically the most
difficult, but has the most pleasing results. A single
KML file is produced directly by the Fortran
program, with no need for post-processing. The files
are of a much more manageable size. Finally, this
method allows us to treat the contour lines & regions
as first-class entities, and manipulate them as such
within GE. So, for example, if only regions between
a certain two values are of interest, they can be easily
identified within the GE browser, and the display of
all others turned off.
There are a number of published algorithms (see
[9] and references therein) for generating contour
images from fields of numbers. However, we
particularly needed one which would identify the
contour lines per se, rather than merely the final
image - and we also needed one which was either
already, or could be easily, implemented in Fortran,
since we wished to avoid any external dependencies
and cross-language linking.
Thus we chose the method of van Snyder[10].
This produces contour lines rather than an image, and
the published paper includes a primitive Fortran
implementation. Several adaptations were necessary,
not least in order to generate the contour regions,
which proved non-trivial. However, the result is
robust and expressible in standard Fortran.
The construction of WKML was driven by several
use-cases, where an existing Fortran code output
geographical data, which users wished to look at
within Google Earth. Here we show three typical
cases.
5.1 hypoDD
The simplest use case for WKML is when a
program produces a series of latitude/longitude
points, which the user wants to view on a map. Our
use-case for this was the seismological program
hypoDD[11]. hypoDD analyses a series of
measurements of seismic events, taken from various
earthquake-observation stations, and applies the
double-difference algorithm described in [12] to
refine the estimates of the earthquake hypocentres.
This allows error cancellation between observations
from different stations, and results in significantly
improved locations.
Both the input and output to hypoDD are
essentially a series of points, with accompanying
data about earthquake depth and magnitude. The
original version of hypoDD is distributed with a
series of scripts for manipulating and converting the
data, plus accompanying maps, into a format that
Figure 3: hypoDD output - a series of points representing
locations of earthquake hypocenters. Orange circles are
initial guesses, purple are refined estimates. Circle
diameter is proportional to earthquake magnitude.
Matlab can understand, in order that it can be used as
a visualization engine. This is a cumbersome step,
and Matlab is not nearly as well-suited to
geographical visualization as Google Earth
Furthermore, of course, Matlab is not freely
available.
We modified hypoDD to use WKML and directly
output KML in the course of a calculation. When this
modified version is run, additional output is
produced - a KML file containing the positions of the
initial and final estimates of the earthquake location.
This can be immediately loaded into GE, and the
results are shown in Figure 3.
In the simplest case, we could have simply
represented the locations of the refined estimates, by
undistinguished placemarkers. In this case, the
modification of the program would have involved (in
addition to opening and closing the KML file), no
more than one simple line,
call kmlCreatePoints(kf, points)
which is clearly within the reach of any Fortran
programmer, however inexperienced, yet
immediately allows the most important data to be
viewed without further ado.
To aid visualization, however, we also output the
initial positions (so that the difference can be seen),
coloured the points differently according to whether
they are input or output data, and changed their
diameter according to the magnitude of the
earthquake. All this corresponds to the use of a
second kmlCreatePoints call, and of a few
additional optional arguments for colour and size.
Slightly more investment in reading documentation
is necessary, but again this is within reach of any
Fortran programmer.
5.2 GLIMMER
A more complicated visualization requirement is the
presentation of three-dimensional objects.
GLIMMER (GENIE Land Ice Model with
Multiply Enabled Regions)[13] is a glaciological
modelling library - it provides a set of components
for modelling ice-sheet dynamics, and is designed for
inclusion in a more complete earth system
simulation. When invoked, one of its outputs is a
three-dimensional model of an ice sheet - with height
data available for a series of grid points whose
position is available in latitude/longitude.
In the original version this is output in netCDF
[netCDF] format, which is very commonly used for
earth systems data. GLIMMER comes with a set of
tools for reading in these netCDF files and
visualizing them using GMT (Generic Mapping
Tools)[1]. GMT is designed for the purpose of
visualizing earth systems data, and produces highquality publishable figures - but nevertheless is very
poor for interactively exploring data sets, when
compared with GE. GLIMMER is written in Fortran,
and Fortran is the language with which its
developers, and most of its users are most
comfortable. In collaboration with one of the
developers, we constructed Fortran programs for
Figure 4: GLIMMER output - a three-dimensional
model of a Greenland ice sheet, composed of a series
of raised quadrilaterals, coloured according to
height.
reading and transforming the data in these netCDF
files, and used WKML to output models of the ice
sheets for use in GE.
An example is shown in Figure 4, showing a
model of an ice sheet over Greenland. Since we are
modelling a field of data whose z-value directly
represents altitude, the kmlCreateCells
subroutine was used. As can be seen in Figure X., the
display was improved by additional styling,
colouring the cells according to height. For ease of
visualization, the height of the ice sheet has been
multiplied by 10 to exaggerate altitude variation.
5.3 MCHSIM
The most common visualization requirement that we
have come across among earth scientists is the desire
to quickly and easily look at two-dimensional fields
of data in their geospatial context - to be able to take
an arbitrary dataset, and have it shown as either
isocontours or a plot of contour regions on GE.
The Monte-Carlo Hyperspectral Synthetic
Remote Sensing Model (MCHSIM)[14,15] generates
hyperspectral images of water surfaces on the earth.
This is done by simulating the photons passing
through a water column, accounting for various
physical and chemical properties of the water being
studied. These generated images can ultimately be
compared to actual aerial photographs, allowing
refinements to the accuracy of the model and of the
input water properties.
MCHSIM is implemented in a Fortran program
which, when run, calculates a number of quantities,
representing properties of the water surface. These
can later be converted to synthetic images. One
output quantity of particular interest is the calculated
water reflectance across the simulated area. It is very
useful to be able to visualize the variation in
reflectance within GE. For this, we developed and
used the kmlCreateContour subroutine.
Figure 5 illustrates the outcome of this contouring
algorithm for the output of the MCHSIM program.
The quantity represented is a single spectral band of
the calculated water surface reflectance. The
differences in reflectance can clearly be seen with
References
Figure 5: MCHSIM output - varying levels of water
reflectance, illustrated as colour-coded isocontour
lines.
great variation near the coastline, and less in open
water.
6. Conclusion
Google Earth provides a richly interactive, attractive
platform for the visualization of arbitrary geospatial
data. However, the requirement that displayed data
be in KML is a burdensome requirement on the overworked scientist.
We have produced a pure Fortran library,
WKML, which generates KML output to display the
most commonly interesting forms of geospatial data.
Importantly, it requires no knowledge of KML on the
user’s part at all; they are presented with a very
simple API which expects data in the form of Fortran
arrays, in which it is likely to already exist, and will
create graphical elements of the sort which users are
most likely to want.
WKML is openly licensed and freely available full documentation and source may be downloaded
from the project’s website at:
http://www.niees.ac.uk/wkml/
WKML is intended for use both in existing
Fortran codes, where it may be used to produce
directly visualizable output from data-generating
programs, and also in newly developed simulation
and analysis programs.
We have presented three representative use-cases,
where WKML has dramatically improved the facility
with which geospatial data can be visualized, to the
direct benefit of scientists.
Acknowledgements
We would like to acknowledge the invaluable aid of
Dr. Andrew Walker (of Cambridge University, for
assistance with hypoDD), and Dr. Ian Rutt (of
Bristol University, for assistance with GLIMMER).
We would also like to acknowledge the financial
support of the UK Natural and Environmental
Research Council.
[1] A full review is entirely beyond the scope of this
paper, but see for example:
GMT - http://gmt.soest.hawaii.edu,
GRASS - http://grass.itc.it/
[2] http://earth.google.com/kml/
[3] Plescia, J. et al. (Eds.), Eos Trans. AGU, 87(52),
Fall Meeting Supplement (2006)
[4] http://www.uszla.me.uk/FoX/, and see also
[16]
[5] http://www.opengis.net/gml/
[6] http://worldwind.arc.nasa.gov/
[7] http://www.esri.com/arcgisexplorer/
[8] http://www.opengeospatial.org/
[9] Sabin, M. “A survey of contouring methods”
Computer Graphics Forum, 5(4) 325-339 (1986)
[10] van Snyder, W., “Algorithm 531: Contour
Plotting [J6]”, ACM Transactions on
Mathematical Software, 4, 290-294 (1978)
[11] Waldhauser F., Ellsworth, W. L., “A doubledifference earthquake location algorithm: Method
and application to the northern Hayward fault”,
Bull. Seism. Soc. Am., 90, 1353-1368 (2000)
[12] Waldhauser, F., “hypoDD: A computer program
to compute double-difference earthquake
locations”, USGS Open File Reports, 01-113
(2001)
[13] http://glimmer.forge.nesc.ac.uk
[14] Bostater, C., Chiang, G.-T., Huddleston, L. H.,
Gimond, M., “Synthetic Image Generation of
Shallow Waters Using a Parallelized
Hyperspectral
Monte Carlo & Analytical
Radiative Transfer Model” Proc. SPIE, 4880,
102-116 (2002)
[15] Chiang, G.-T., Dove, M.T., Ballard, S., Bostater,
C., Frame, I., “A grid enabled Monte Carlo
hyperspectral synthetic image remote sensing
model (GRID-MCHSIM) for coastal water quality
algorithm”, Proc. SPIE 6360, 636009 (2006)
[16] White, T.O.H., et al., “Application and use of
CML within the eMinerals project”, Proceedings
of the Fifth UK eScience All Hands Meeting.
606-613 (2006)