JGrass and uDig, chronicles of a lovestory

JGrass and uDig, chronicles of a lovestory

a preview of JGrass 3.0

Andrea Antonello - HydroloGIS CUDAM of the University of TrentoUniversity of Urbino

Victoria 2007-09-25

...and at the very first begin there was the GIS... GRASS

...but it seemed to suffer from an academical and poweruser sindrome...

used a lot in academic field, but has problems to get to professionals and public administrations in Italy

created on unix based systems and exploits its capacities on those systems best

as for all the high level things, the level of contents is proportional to the complexity of the initial learning curve

The community feels the need for graphical interfaces

...Qgis, Tcltk, Python, Java...

...and then there was JGrass...

JGrass 1.0

JGrass 1.0 starts in 2004 from the collaboration of the C.U.D.A.M. of the University of Trento and the I.C.E.N.S. of Kingston

the aim is to expand GRASS with a usability such to get it out of the academic environment to the average user

it gets born basically as a java GUI to GRASS released under GPL

the project encounters difficulties to expand and build up a community, in part because of the java-choice, which was criticised to be non-GPL

the major sponsor is the C.U.D.A.M. through projects

JGrass choses a precise direction:the protection and modeling of the territory

JGrass 1.0 environmental modeling? So what?

...it gets filled up with tools developed at the University of Trento, department of hydrology and hydraulic, Faculty of Engineering

hydro-geomorphologic models that work on raster basis

JGrass 1.0 creation of profiles

JGrass 1.0 raster map algebra

JGrass 1.0 statistical analysis and reports

JGrass 1.0 definition of environmental attributes

rainfall data

drainagedirection

networkextraction

totalcontributingarea

rescaleddistancesand hydrologicattributes

slope,curvaturesand geo-morphologicattributes

JGrass 1.0 Peakflow: the hydrologic model in JGrass

JGrass 1.0 Shalstab: hillslope stability

JGrass 2.0 searching for a community

JGrass 2.0 searching for a community

2006 JGrass 2.0 is released

it tries to follow the users needs, that find it very scientific but rather useless if I can't view my shapefile in it

there is an effort to create a community, since the number of stable developers at that time was oscillating between 1 and 2

the foundings are not many more than before and the development goes on in the direction of those who pay

however some voluntary work is done getting in touch with the geotools technology in order to gain some rudimentary vector support

JGrass 2.0 support for shapefile/postgis

JGrass 2.0 support for dwg files

JGrass 3.0 do not reinvent the wheel please...

At the begin of 2007 the JGrass team decided:

that they had suffered enough in their solo trip

that they had to join one of the other vector supporting java gis community (which wasn't an easy choice, Jump-flavors, GvSig, uDig)

in the end to join the uDig community because of their clean framework and amount of documentation

in fact the choice was good, we got a lot of startup help from the udig community, the eclipse documentation did the rest and we assume that with really few developers this transition part will be finished by february 2008, i.e. a year

JGrass 3.0 joining the udig community

Advantages:

find a helpful community based on bussiness mentality

a mature and stable base framework with available literature

a plugin system with extention points that force to a clean and robust development

Disadvantages:

rather steep development learning curve

uDig isn't an analysis application

in fact the choice was good, we got a lot of startup help from the udig community, the eclipse documentation did the rest and we assume that with really few developers this transition part will be finished by february 2008, i.e. a year

JGrass 3.0 what is behind it?

the GRASS raster service

the JGrass Console

OpenMI

BIRT and charting

The GRASS raster service

first thing was adding native support for GRASS rasters in read/write mode and a udig service was created for the GRASS workspace



GRASSDB: folder that holds all the locationsLOCATION: holds the information of the used projection, holds all the mapsetsMAPSET: the user space inside which the active working region is definedPERMANENT: particular mapset used to hold location informationsACTIVE REGION: the region definition (boundaries and resolution) inside which most GRASS commands apply







grass-ascii rasteresri-ascii rasterfluidturtle raster

The active region


Colortables and categories

GRASS rasters support color ramps

Colortables and categories

GRASS rasters support categories

How to access a raster map?

GRASS raster service issues

GRASS saves a PROJ_INFO file in the PERMANENT mapset, but that file can't be built without GRASS functions. So for now there is the need to create a PROJ_INFO.WKT in the same folder. If that file is not present, the user is asked to chose a projection.

Reprojection on the fly is not possible. A GRASS workspace has a predefined projection and all the maps are consistent with that. So at the moment if you are working with a GRASS workspace, that one ist the first to be dragged into the project, in order to define the projection of the map.

uDig doesn't support dragging folders into the catalog, so if you want to drag the GRASS location into the catalog, you first need to create an empty file with .jgrass extention. Drag that and the magic is done.

GRASS doesn't support alpha as a persistent value. JGrass does it by putting the alpha as a comment into GRASS's colorfile.

Not yet completely resolved issues:

JGrass 3.0 the JGrass console

support java scripting (beanshell)

be extensible

support the JGRASS model language based on openMI standards

support native GRASS commands

be usable in batch mode in order to be used for example in web environments (geoserver?)

The JGrass console

click on the console icon

the editor appears with a few advices

rightclick gives the menu needed for execution

The JGrass console java scripting with beanshell

beanshell is supported

methods can be defined

simplified java can be used

rightclick and chose run from the menu

the content of the window is executed inside the editor's own console

The JGrass console getting GRASS into the game

on whatever environment, if a GRASS installation is present, it can be exploited

a preferences page defines the needed paths


with GRASS configured the commands can be executed by wrapping them into grass{}

example output of r.info


with GRASS configured the commands can be executed by wrapping them into grass{}

example output of r.info

ask for help if you don't know the usage

The JGrass console the JGrass Modeling Language

support was created for the JGrass Modeling Language

it is based on OpenMI Linkable Components, that base on their fundamental methods:

...and other methods like prepare, finish and those for linkage

those components can be linked together into a pull mechanism and executed within a time interval

The JGrass console OpenMI

OpenMI is a set of standard interfaces that defines interaction between environmental models

they are beeing used worldwide on important hydrologic and hydraulic projects as obec, modflow and even Hec-Ras

there is no real standard for OGC in it, so for JGrass we extended the interfaces to support the feature model and RaserData, which is basically a bounding box with a defined resolution


jgrass models are wrapped into jgrass{}

variables can be used from the beanshell environment by using the $ sign

return values can be asked from the values and they then can be used in the beanshell environment

this gives the possibility to easyly create also complex algorythms without having to know the whole development framework write and execute!


from the jgrass modeling language syntax on compiling time the openmi linkable components are created and linked together properly

also nesting of models is supported and those are linked together at runtime

Regarding OpenMI:

when run or compile is clicked some magic happens: the content of the editor is passed thorught a compiler which generates the openmi based components.

the model above would then look like...




Introducing time:

rightclicking gives access to the session preferences

a different workspace can be set for different console sessions

time dependency with defined timesteps can be added

the models are then executed in a loop increasing the timestep

The JGrass console ongoing and future work

integration of the statistic R package into the scripting as R{} blocks

creation of the Visual Console based on the GEF framework

JGrass 3.0 starting with BIRT's smallest part: charting

eclipse based reporting system

does report creation as simple lists of data, more complex, also letters and documents etc etc... and...

CHARTS!

JGrass 3.0 the chart view the profile tool

r.profile tool opens the chart view

clicking on the map shows the profile over the selected map




preferences can be set




preferences can be set

and the chart looks much better...

JGrass 3.0 what if 3 is a dimension?

integration of the VISAD scientific library

famous for its datamodel

supplies a 3D rendering system based on java3D

JGrass 3.0 tools for fieldmapping

shapes creation in runtime through a NMEA GPS

possibility to chose type of shape, stop, save, start from scratch or create multiple shapes

JGrass 3.0 conclusioni

JGrass 3.0 release is expected for February 2008

released at the MIGG2008 course for geomorphologic modeling

www.jgrass.org

R support

GRASS vectors support (European Code Sprint in November?)

JGrass and uDig, chronicles of a lovestory

a preview of JGrass 3.0

FOSS4G 2007

FOSS4G 2007

Technology

JGrass and uDig, chronicles of a lovestory