oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From AMILA RANATUNGA <newair...@gmail.com>
Subject Re: Research project on integrating geoservices with Apache Airavata
Date Sat, 06 Apr 2013 04:25:27 GMT

Thank you for the long reply. As you suggest "GeoTk" is the core part which
suits to scientists. And "Constellation-SDI" is intended to
provide web-services using maximum use of those tools. Constellation-SDI
consisted of WPS, WMS, WFS as server modules. So will that integration make
Apache SIS be considered as those services enabled?

And why you said " Having SIS to implement WMS, WMTS, WCS and WFS is a must"?
What about WPS. Will that make SIS out of the scope. Because we feel that
since Airavata using Science gateway concept, really essential to implement
WPS too.

Thank You !

On Fri, Apr 5, 2013 at 7:04 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message