Linking environmental models together tomake the world a better place: the GIS

approach

Geoinformatics FCE CTUPrague, Czech Republic, 19th of May 2011

Andrea Antonello (HydroloGIS)Olaf David (Colorado State University/USDA)

The importance of being... GIS

a container for environmental sciences...

Horton Machine, geo-hydro toolbox inGRASS

JGrass, hydro-geomorphology based onGRASS formats

• first wanted to be a userfriendly gui for GRASS

• a toolbox for geomorphology and hydrology

Soon it became clear what was missing to make the world

a better place:

• a standard (accepted) modelling system

• a modern, mature and extensible rich client

framework

uDig, the GIS app to create apps

...the glue for different applications?

The reciepe so far:

• GIS

• a fair amount of

science

• ?

What do we mean when we say linkingmodels?

A simple example

ESRI ASCII, TIF, GRASS COVERAGE READER PITFILLER

ESRI ASCII, TIF, GRASS COVERAGE WRITER

Still a simple example

ESRI ASCII, TIF, GRASS COVERAGE READER PITFILLER

ESRI ASCII, TIF, GRASS COVERAGE WRITERFLOWDIRECTIONS

Still a simple example, but trickier

ESRI ASCII, TIF, GRASS COVERAGE READER PITFILLER

ESRI ASCII, TIF, GRASS COVERAGE WRITERFLOWDIRECTIONS

ESRI ASCII, TIF, GRASS COVERAGE WRITER

But what about this?

RESCALED DISTANCE SUP E SUB

ESRI ASCII, TIF, GRASS COVERAGE READER

PITFILLER

FLOWDIRECTIONS DRAIDIR

EXTRACTNETWORK

GRADIENT

CURVATURES

AB

TOPINDEX

PEAKFLOWRAINFALL AND SATURATION PARAMETERS

CSV, DATABASE WRITER

And this?

CSV, DATABASE READER

ENERGY INDEX

KRIGINGrain interpolation

ENERGY BALANCE

SNOW, GLACIER VEGETATION PARAMETERS

CSV, DATABASE WRITER

Pnet, SWE

SHAPEFILE AND POSTGIS READER

tem

pera

ture

pre

ssure

rela

tive h

um

idity

win

d s

peed

rain

basinsrain gauges basins

meteo stations

rain

tem

pera

ture

pres

sure

rela

tive

hum

idity

win

d sp

eed

basins

JAMI other meteointerpolation

And then there is time

Consider there will be parameters and modules that execute just once, theremight be an external timeline, which could even be paused when no data areavailable.

CSV, DATABASE READER

ENERGY INDEX

KRIGINGrain interpolation

ENERGY BALANCE

SNOW, GLACIER VEGETATION PARAMETERS

CSV, DATABASE WRITER

Pnet, SWE

SHAPEFILE AND POSTGIS READER

tem

pera

ture

pre

ssure

rela

tive h

um

idity

win

d s

peed

rain

basinsrain gauges basins

meteo stations

rain

tem

pera

ture

pres

sure

rela

tive

hum

idity

win

d sp

eed

basins

JAMI other meteointerpolation

t

1x calc

pause dt 1x param

What other problems do we have for a modellingenvironment to work?

• modules come from different authors

• modules come in different.. ehm flavours

• nowadays it should be possible to load library

modules at runtime

• they should not change the original code too much

• to be able to connect them, the modules need to be

datatype abstract

• ...and possibly have the timeline external

What do we mean when we say linking models?

DATA READER MODULE 1 DATA WRITER

inputFilePathForModule1 outputFilePathOfModule1

DATA READER MODULE 2 DATA WRITER

t1...tn t1...tn

DATA READER

MODULE 1

DATA WRITER

inputFilePathForModule1 outputFilePathOfModule1

t1MODULE 2

tn

The (European) OpenMI approach

Considering that:

• OpenMI seemed to become de facto a standard (still)

• important actors in hydrology (ex. DHI and Deltares)

• OpenMI was missing GIS notions

We decided to:

• invest two years to migrate our modules to that

framework

• invest time and resources to join the technical

steering committee

The (European) OpenMI approach

The modelling approach was the usual. Init your thing,

then execute, at the end dispose.

public void initialize( IArgument[] properties ) throws Exception { // ...}

public IValueSet getValues( ITime time, String linkID ) throws Exception { // ...}

Being OpenMI a set of standard interfaces, the

user/developer is forced to follow those apis.

The (European) OpenMI approach

We learned that:

• for our purposes the framework was too invasive (for

large models than many small modules?)

• migration effort was too big

• by the time we finished a new major release was

ready

• at that time we were the only ones supplying open

source modules (so who to test linking with?)

• back then we never were able to get GIS stuff into

OpenMI (now they discuss with OGC)

The (American) OMS3 approach

At a conference our team came in touch with the Object

Modelling System.

Welcome to the Object Modeling System ... modeling

framework ... based on components ... project active

among the U.S. Department of Agriculture and partner

agencies ... highly inter-operable and lightweight

modeling framework for component-based model and

simulation development on multiple platforms.

Well, we had heared that before.

Annotations on your code

Basically OMS3 supplies a set of Annotations to put on

the code to describe it.

Class description useful for the generation of

documentation and guis.

@Description("It fills the depression points present within a DEM.")@Documentation("Pitfiller.html")@Author(name = "David Tarboton")@Keywords("Dem manipulation, Geomorphology, DrainDir")@Label(JGTConstants.DEMMANIPULATION)@Name("pit")@Status(Status.CERTIFIED)public class Pitfiller { // ...}

Definition and description of input and output parameter

@Description("The map of digital elevation model (DEM).")@Inpublic GridCoverage2D inElev;

@Description("The depitted elevation map.")@Outpublic GridCoverage2D outPit = null;

Definition of the method to be executed

@Executepublic void process() throws Exception { // ...}

What about native code?

How does OMS3 help?

• Use FORTRAN code in OMS directly (no C/C++

bridge required)

• Define OMS components in FORTRAN

• Integrated with build system

• Allow automatic documentation generation from

source

Requirements?

• FORTRAN 90+ syntax

• ISO_C_BINDING

• GCC 4.4+ / gfortran

! @ExecuteSUBROUTINE we(eroout, eroout_len,runoff,peakro,effdrn)

! @In CHARACTER(kind = C_CHAR, len = eroout_len) :: eroout INTEGER(C_INT), intent(in), VALUE :: eroout_len

! @In REAL(C_FLOAT) :: runoff,peakro,effdrn ..

http://gcc.gnu.org/onlinedocs/gfortran/ISO_005fC_005fBINDING.html

OpenMI vs. OMS3: our experience

Extending OMS3 with GIS: the genesis ofJGrasstools

OMS3 brought some important advantages:

• USDA has lots of open source OMS3 modules

• flat learning curve for instant gratification

• fast migration of code

• abstraction of I/O is perfect choice, clean code

• possibility of external handling of the timeline

We decided to not migrate JGrass to use OMS3, but

instead to extract the processing algorithms to a

geomorphologic and hydrologic library, the

JGrasstools.

What can we find in JGrasstools?

Engineering

Major environmental models:

• hydro-geomorphological risk

• hydropower, solar potential and renewable energies

• LiDAR data analysis

Maximum discharge: Peakflow

Interpolators: Kriging, Jami

Full hydrological cycle: Adige, Hymod

Snowmodel, simplified hydraulic model

Network Management

Powerful and well known software for water supply

system and stormwater network system design and

maintainance:

• Epanet

• Trento_p

Epanet integration in uDig

The Horton Machine: geomorphologic and hydrologictoolbox

http://code.google.com/p/jgrasstools/wiki/HortonMachine

JGrass gears: generic GIS toolbox

http://code.google.com/p/jgrasstools/wiki/JGrassGears

How to use JGrasstools

• in applications (see Epanet for uDig)

• through the scripting engine (groovy, oms, geoscript)

sim = new oms3.SimBuilder(logging:'ALL').sim(name:'pitfiller') { model { components { 'pitfiller' 'pit' 'reader' 'rasterreader' 'writer' 'rasterwriter' } parameter { 'reader.file' 'D:\\data\\spearfish60new\\user1\\cell\\dtm' 'writer.file' 'D:\\data\\spearfish60new\\user1\\cell\\pit' } connect { 'reader.outRaster' 'pitfiller.inElev' 'pitfiller.outPit' 'writer.inRaster' } }}sim.run();

• from commandline

./jgrasstools.sh script.oms

So what about normal users??

OMS3, GIS and JGrasstools made simple

Introducing the OmsBox

user frontend

the OmsBox is a frontend for GIS users, a a

graphical user interface that can load any OMS3

annotated module

uDig based

eclipse/rcp/uDig plugin to integrate in GIS. Mouse

clicks, region settings, raster resolution and all

needed GIS notions are supplied to the widgets

oms3 generated guis

the guis are generated from the OMS3 annotations.

The GIS knows only OMS3.

gui labels and docs

the gui labels and documentations are now

responsability of the module developer/maintainer

licensing issues

the OmsBox is a LGPL plugin for uDig (compatible

with OMS3). Loaded OMS3 libraries can choose the

license. JGrasstools is GPL.

The OmsBox in uDig

• integrated in uDig

• drag & drop

• listens to clicks

• region settings auto-fill

• different debug levels

• separate processes

OmsBox gui generation: @Label

OmsBox gui generation: ClassName

OmsBox gui generation: @In/@Out fields

OmsBox gui generation: field @Description

OmsBox gui generation: field @Units and @Range

OmsBox gui generation: on the fly documentation

OmsBox gui generation: on the fly documentation

Geoinformatics FCE CTUPrague, Czech Republic, 19th of May 2011

Useful links:

• http://www.javaforge.com/project/oms

• http://www.jgrasstools.org

• http://udig.refractions.net

• http://www.geotools.org