Hi, 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 < [email protected]> 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 >> 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 > >
