Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <51652E0A.8030106@geomatys.fr>
Date: Wed, 10 Apr 2013 11:16:58 +0200
From: Martin Desruisseaux <martin.desruisseaux@geomatys.fr>
Organization: Geomatys
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Nipuni Perera <nipuni880917@gmail.com>
CC: AMILA RANATUNGA <newair007@gmail.com>,
 "dev@sis.apache.org" <dev@sis.apache.org>,
 dev@airavata.apache.org, Harsha Kumara <harsz89@gmail.com>,
 Shahani Markus Weerawarana <shahani.w@gmail.com>,
 "dev@oodt.apache.org" <dev@oodt.apache.org>
Subject: Re: Research project on integrating geoservices with Apache Airavata
References: <33907205-9B61-46CF-B2E2-98DB5C4B3D2F@apache.org>
 <CD82F26F.C5C1A%chris.a.mattmann@jpl.nasa.gov>
 <CADUUiyG_eU=ArUgPv+h=EbRbvV_=DtvoCgXKXaXwJuMM__TiTg@mail.gmail.com>
 <515ED2CD.40103@geomatys.fr>
 <CADUUiyHzqraroFKQyOGZrxXtW-w6+_WhRFDVqNiB2F0_Mhh66w@mail.gmail.com>
 <5161976F.6040101@geomatys.fr>
 <CAF-9AYkrP_USQjeXioN4aZT2YJjG+hN6=5RjBU_WdUU4DzrJmA@mail.gmail.com>
In-Reply-To: 
 <CAF-9AYkrP_USQjeXioN4aZT2YJjG+hN6=5RjBU_WdUU4DzrJmA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello Nipuni

Le 10/04/13 09:52, Nipuni Perera a �crit :
> According to our understanding so far we feel that SIS can be used to 
> implement a server which exposes OGC web services such as WPS.

Actually SIS is not yet there, but this is clearly the goal. In current 
situation however, peoples wanting WPS would need to complete SIS with 
other projects until we completed the port of those projects to SIS.

> If  SIS can be used as a library for underlying geospatial processes 
> what makes  it different from currently exposed services. Because we 
> have seen that Taverna also has the ability to create geoscience 
> workflows using some web processing services.

Different libraries have different pro and cons. Given the large variety 
of geospatial formats, you may find that for some data, library A 
behaves better than library B, and for other data library B behaves 
better than library A. There is also different implementation trade-offs 
which impact accuracy. For example the "Geospatial integrity of 
geoscience software (GIGS)" test suite recognizes two kinds of 
referencing engine: "early binding" and "late binding" [1]. GIGS 
recommends the "late binding" model, but recognizes that many products 
use the "early binding" model for simplicity. To code to be ported to 
SIS implement a "late binding" model, while some other popular projects 
implement an "early binding" model.

I think that SIS will focus more on science than many other projects. In 
our participation to an other project before we came to Geotk/SIS, we 
were the ones who insisted that we can not interpolate RGB colors in a 
raster of Sea Surface Temperature (SST); we need to interpolate 
temperatures, then convert to RGB values using the color map. In areas 
of thermal front, the two approaches produce very different colors. 
Non-scientists may be more inclined to handle the rasters as ordinary 
RGB images for simplicity, which is great for mass-market but not 
appropriate for geophysics data. Geotk/SIS also implement "map 
projection derivatives". In numerical calculations, knowing the 
derivative of a function often allows faster and more accurate 
calculations. In the case of map projections, this allow more accurate 
calculation of envelopes. Since "function derivatives" is a relatively 
"advanced" mathematical concept, I'm not aware of any other open source 
GIS projects implementing them. The fact that we implement them show our 
inclination for sciences. The efforts that we are putting in GIGS tests 
also show our efforts to ensure correctness or, when we are wrong, to 
get an estimation of our error. This greater attention given to 
uncertainties is also a symptom of more science-inclined projects.

In an ideal world, you should be able to code against GeoAPI interfaces 
[2] and choose different implementations according your needs. This is 
the same goal than JDBC interfaces, which allow applications to use 
different database engine. GeoAPI has not yet reached this level of 
acceptance unfortunately, but you may still be able to isolate your 
application from the library by using GeoAPI interfaces when they suit, 
or your own set of interfaces (maybe as temporary interfaces until we 
fill the holes in GeoAPI) for the missing parts.

     Regards,

         Martin


[1] http://www.ogp.org.uk/pubs/430-1.pdf section 3.4
[2] http://www.geoapi.org/