Hi,
parallel to WCS 2.0 and its EO extension (that will be worked on in 2013) we are also
looking into supporting WMS EO.
The WMS EO adds some requirements on top of the usual WMS 1.3, in particular,
it demands that earth observation product are presented in a particular
way in the capabilities document, and has some weirdness in the way GetMap has
to be executed on them.
I’m going to report the significant bits, the whole specification can be found here:
http://portal.opengeospatial.org/files/?artifact_id=30912
The EO product is meant to be a mosaic with time dimension, and has to be proposed
as a layer tree in the capabilities, looking as follows:
- product (default view), let’s assume it’s named eoproduct
- coverage outline (the polygons containing the single mosaic granules, a vector layer)
named eoproduct_outlines, optional - a layer exposing the rater bands with a custom dimensions (not elevation or time),
one value per band, called eoproduct_bands, optional - one or more layer exposing geophysical parameters of the coverage (normally
derived from the bands though analysis) called eoproduct_paramName - one or more bitmask layers representing on/off information about the coverage, such
as the cloud presence, snow presence, land and so on. Each one would be called
eoproduct_maskName
The first weirdness of the above is that the root of the tree is a layer per se, it’s
not a mere container.
That is, if you invoke just it, you won’t get the normal “group” behavior, getting all
the layers inside of it, but a fixed representation which is called the default view.
For example, if you have a landsat 7 bands with all the sublayers, the default
view would probably be a choice of 3 bands giving the user a quick preview
of the data in the visible range.
The above is against the normal workings of the WMS protocol, but it’s mandatory
in WMS E/O.
The second weirdness is related to managing the bands layers. The spec say that
you can specify either one value for the band dimension, or three, any other
combination should throw an exception.
If one is chosen, the representation will be grayscale, if three are chosen, they
will be used as R, G and B respectively to build a falso color representation.
This is, guess what, against the normal WMS behavior.
Soo… how do we want to go about it? Three steps.
First, we’d like to add a flag to layer groups allowing the layer group to be
“exposed”, “unfolded”, that is, shown in its internal structure in the capabilities
document.
When the flag is activated, the layers in the group will disappear from the
normal list, and be contained below the group instead.
We’ll setup something to handle cases where the same layer is in multiple
exposed groups, such as “first wins” or throw some configuration exception,
in order to maintain a valid caps document (as far as I remember, a layer
can appear only once in the layer tree).
This functionality has been requested in the past in the user list, we believe
it’s going to be useful outside EO.
Second, add the concept of a “root layer” in the groups, which would be
used only in exposed layers, and that would play the part of the layer
exposed when the root is requested, in order to cover the “default view”
requirement of EO.
This one is a bit weird, but I cannot think of a pluggable way that would
allow a EO plugin to get the desired, it seems something that has to be
configured in the catalog.
We should also open an extension point allowing a plugin to manipulate
the MapContent right before the map gets rendered.
This plugin would recognize the bands layer, look at the dimensions,
and create on the fly the appropriate SLD style to do the band merging
on the multiband layer.
Finally, it would be nice to have some sort of wizard allowing someone
to setup the EO group starting from an image mosaic, without having
to create everything manually.
The last two could be a good fit for a WMS-EO extension, while the
first two dealing with layer groups would be core.
Opinions?
We would like to start the development shortly, sometimes next week
(of course, if things are ok we’ll do a GSIP for the layer groups changes)
Cheers
Andrea
–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it