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
GEOAPI.
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 (...snip...)
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.
Martin
