oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Desruisseaux <martin.desruisse...@geomatys.fr>
Subject Re: Research project on integrating geoservices with Apache Airavata
Date Fri, 05 Apr 2013 13:34:05 GMT
Hello Amila

Le 05/04/13 12:57, AMILA RANATUNGA a écrit :
> the slide 21 describes remaining code to move as WMS, WCS, WCTS, WPS and
> more. Is that mean Apache SIS does not support them?

Yes. SIS is still in an early stage and does not support WMS, WCS and 
similar services yet.

> And GeoTk code was moved to SIS and claims that reference implementation of

Geotk code is in process of being moved to SIS. But only metadata port 
is close to completion. The next module to port will be referencing 
(hopefully completed before FOSS4G in September).

> geotoolkit.org (...snip...) Mapfaces (...snip...) constellation-sdi (...snip...) puzzle-gis
> Will integrating those into sis make one step ahead to "SIS well-suited to
> some communities (*scientists, but also non-scientists* wanting to explore
> data in more dimensions than the usual x,y)."?

Maybe I should said that those projects will not be automatically added 
to SIS. They will be offered, but by the time we reach them, the 
technologies may have evolved to a point where peoples may want to 
explore other approaches. For example MapFaces is built on top of JSF. 
But maybe some peoples will want to explore the Play framework instead. 
An other example is Swing-based technologies, which are going to be 
phased out in favour of JavaFX. However we may still use the existing 
code as a starting point and try to port them to the new technologies. 
We will revisit this issue when we will be there.

The core part aiming to make SIS "well suited to scientists" is Geotk. 
First by its focus on ISO 19115 metadata for describing the data. Those 
metadata include a package for describing data quality, an aspect 
usually neglected by mass-market projects but important for scientists. 
The GeoTk (future SIS) referencing module takes its information directly 
from the EPSG database, which provides us information about 
transformation accuracy and CRS (Coordinate Reference System) area of 
validity. Many popular projects use simplified version of EPSG database 
without those information, since not anyone see them as useful. GeoTk 
paid high attention to correctness through our current effort of 
expanding 'geoapi-conformance' test suite with the GIGS tests (provided 
by the EPSG authors). GeoTk also have support for n-dimensional CRS. 
Those CRS may be more than (x,y,z,t), for example meteorologists use 2 
time axes and oceanographers often use pressure instead of z. On the 
coverages (rasters) side, GeoTk provides a way to describe the meaning 
of pixel values (by contrast with some projects handling rasters 
basically as RGB images), which allow for example to compute "gradient 
of sea surface temperature" without confusing a temperature value with a 
pixel covered by a cloud (without such knowledge, calculations like 
"gradient" produce strong artefacts). Large dataset can be organized in 
a database schema designed for making easier the statistical analysis 
over time series.

Constellation-SDI simply uses the "building blocks" provided by 
SIS/GeoTk for providing web services. Our approach for aiming such web 
services as "well suited to scientists" is to make sure that we use 
properly the tools provided by SIS. Similar reasoning apply to 
Puzzle-GIS. Providing those web services and desktop application 
directly in SIS would allow SIS to run "out of the box", but community 
may decide that this is not a goal.

> We also referred the white paper[2].There are OGC compliance products and
> OGC implementing products[3]. What is the main difference? For an example
> zoo project is considered as OGC implementing. But the site says " It
> provides an OGC WPS compliant developer-friendly framework to create and
> chain WPS Web services".

I suspect that "OGC compliant products" and "OGC implementing products" 
can be understood as synonymous. However Frédéric Houbie would known better.

> As Jun mentioned Osgeo live dvd has many products [4]. If they are
> compliance with OGC. implementing OGC standards with Airavata will make
> such products inter-operable with Airavta. But those have implemented
> specific OGC standards (As Martin said " I think that OGC standards are so
> large that no single software in the world implement all of them"). So for
> such a project what will be the major consideration should be. Or how far
> an integration SIS with Airavata will solve this problem?

The Web Map Services (WMS) is probably the most widely implemented OGC 
standard. Having SIS to implement WMS, WMTS, WCS and WFS is a must. 
Those 4 standards will probably allow inter-operability with the vast 
majority of OGC-compliant products.

Next, there is other standards not as-widely known but nevertheless of 
interest for us. For example Web Processing Services (WPS) for launching 
calculations on distant machines. SensorML for expressing sensor data 
(e.g. monitoring environmental parameters). There is an ungoing 
"uncertainties" working group at OGC which may be seen as a specialized 
work for geoscientists. There is also other groups like "hydrology", 
"aviation" and "law enforcement" for policemen. "Law enforcement" is an 
example of OGC work which will probably not by my personal priority. 
This illustrates the idea that a single project may not implement every 
OGC standards.

Next, there is what OGC calls "best practice" for specific domains. For 
example the OGC Met-Ocean working group has emitted recommendations 
about the way to use WMS with meteorological and oceanographical time 
series. This is because meteorologist have specialized needs for example 
in the way to handle time, not considered of common interest enough for 
being part of the base WMS standard. Those recommendations are a kind of 
gray area, not official standards but nevertheless something we should 
comply to if we want to increase the chances to be inter-operable with 
Meteo-France or the UK MetOffice.


View raw message