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/
