The JGrass team has spent the last 5 years to try to create an appropriate ecosystem for researchers to share their knowledge and for professionals to have innovative tools at hand. The long road lead through various applications and libraries, from GRASS to JGrass, from JGrass to uDig, from OpenMI to OMS. The current scenario presents a central library, the JGrasstools, and the desktop GIS framework uDig. All glued through the OMS3 modeling system, a code annotation framework developed in joint effort between Colorado State University and USDA, that supports the connection between models from different authors and domains.

1. Linking environmental models together to
make the world a better place: the GIS
approach
Geoinformatics FCE CTU
Prague, Czech Republic, 19th of May 2011
Andrea Antonello (HydroloGIS)
Olaf David (Colorado State University/USDA)

2. The importance of being... GIS
a container for environmental sciences...

3. Horton Machine, geo-hydro toolbox in
GRASS

4. JGrass, hydro-geomorphology based on
GRASS 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

5. uDig, the GIS app to create apps

6. ...the glue for different applications?
The reciepe so far:
• GIS
• a fair amount of
science
•?

7. What do we mean when we say linking
models?
A simple example
ESRI ASCII, TIF, GRASS ESRI ASCII, TIF, GRASS
COVERAGE READER
PITFILLER COVERAGE WRITER

8. Still a simple example
ESRI ASCII, TIF, GRASS
COVERAGE READER
PITFILLER
ESRI ASCII, TIF, GRASS
FLOWDIRECTIONS COVERAGE WRITER

9. Still a simple example, but trickier
ESRI ASCII, TIF, GRASS ESRI ASCII, TIF, GRASS
COVERAGE READER
PITFILLER COVERAGE WRITER
ESRI ASCII, TIF, GRASS
FLOWDIRECTIONS COVERAGE WRITER

10. But what about this?
GRADIENT
ESRI ASCII, TIF, GRASS
COVERAGE READER
CURVATURES
PITFILLER
FLOWDIRECTIONS DRAIDIR AB
EXTRACTNETWORK
RESCALED DISTANCE
SUP E SUB TOPINDEX
RAINFALL AND PEAKFLOW
SATURATION CSV, DATABASE
PARAMETERS WRITER

11. And this?
ity
wind e humid
pres rature
d
ENERGY INDEX
relativ re
spee
tempe
su
CSV, DATABASE
READER
ity
rela ssure ture
JAMI
pe mid
rain
pre pera
other meteo
d s hu
ed
win tive
tem
interpolation
KRIGING rain
rain interpolation
ENERGY BALANCE
basins s o ns
sin tati
rain gauges ba teo s
me
Pnet, SWE
ns
SHAPEFILE basi
AND POSTGIS
CSV, DATABASE
READER SNOW, GLACIER WRITER
VEGETATION
PARAMETERS

12. And then there is time
Consider there will be parameters and modules that execute just once, there
might be an external timeline, which could even be paused when no data are
available.
1x calc
ity
wind e humid
pres rature
d
ENERGY INDEX
relativ re
spee
tempe
CSV, DATABASE su
READER
ity
rela ssure ture
JAMI
pe mid
rain
pre pera
other meteo
d s hu
ed
win tive
tem
interpolation
KRIGING rain
rain interpolation
basins
rain gauges
SHAPEFILE
AND POSTGIS
sin
s
ba teo s
me
tati
on
basi
ns
s
t ENERGY BALANCE
Pnet, SWE
CSV, DATABASE
READER SNOW, GLACIER WRITER
pause dt VEGETATION
PARAMETERS
1x param

13. What other problems do we have for a modelling
environment 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

14. What do we mean when we say linking models?
inputFilePathForModule1 t1...tn outputFilePathOfModule1
t1...tn
DATA READER
MODULE 1 DATA WRITER DATA READER
MODULE 2 DATA WRITER
inputFilePathForModule1
outputFilePathOfModule1
DATA READER DATA WRITER
MODULE 1 MODULE 2
t1
tn

15. 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

16. 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.

17. 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)

18. 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.

19. 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 {
// ...
}

20. Definition and description of input and output parameter
@Description("The map of digital elevation model (DEM).")
@In
public GridCoverage2D inElev;
@Description("The depitted elevation map.")
@Out
public GridCoverage2D outPit = null;
Definition of the method to be executed
@Execute
public void process() throws Exception {
// ...
}

21. 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

22. Requirements?
• FORTRAN 90+ syntax
• ISO_C_BINDING
• GCC 4.4+ / gfortran
! @Execute
SUBROUTINE 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

23. OpenMI vs. OMS3: our experience

24. Extending OMS3 with GIS: the genesis of
JGrasstools
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.

25. What can we find in JGrasstools?
Engineering
Major environmental models:
• hydro-geomorphological risk
• hydropower, solar potential and renewable energies
• LiDAR data analysis

26. Maximum discharge: Peakflow

27. Interpolators: Kriging, Jami

28. Full hydrological cycle: Adige, Hymod

29. Snowmodel, simplified hydraulic model

30. Network Management
Powerful and well known software for water supply
system and stormwater network system design and
maintainance:
• Epanet
• Trento_p

31. Epanet integration in uDig

32. The Horton Machine: geomorphologic and hydrologic
toolbox
http://code.google.com/p/jgrasstools/wiki/HortonMachine
JGrass gears: generic GIS toolbox
http://code.google.com/p/jgrasstools/wiki/JGrassGears

33. 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:dataspearfish60newuser1celldtm'
'writer.file' 'D:dataspearfish60newuser1cellpit'
}
connect {
'reader.outRaster' 'pitfiller.inElev'
'pitfiller.outPit' 'writer.inRaster'
}
}
}
sim.run();

34. • from commandline
./jgrasstools.sh script.oms
So what about normal users??

35. 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

36. 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.

37. The OmsBox in uDig
• integrated in uDig • region settings auto-fill
• drag & drop • different debug levels
• listens to clicks • separate processes

38. OmsBox gui generation: @Label

39. OmsBox gui generation: ClassName

40. OmsBox gui generation: @In/@Out fields

41. OmsBox gui generation: field @Description

42. OmsBox gui generation: field @Units and @Range

43. OmsBox gui generation: on the fly documentation

44. OmsBox gui generation: on the fly documentation

45. Geoinformatics FCE CTU
Prague, 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