In this case, my raster is a DEM stored as a single band GeoTiff
(float32). So I'm not concerned with color bands at all. In fact, I'm
not even displaying the raster. I'm only using it to return data to the
user about elevation. The client is AJAX based, so I _could_ issue a WCS
request from the server, open the resulting raster, and get the value
I'm looking for but this seems like a lot of work. Might be easier use
some external library on the server side to respond to the query.
As to multiband, colored geotiffs, I think abstracting the bands as RGBA
attributes makes sense. If color value is tied to some scale then it
would be useful to grab that particular value and process it.
Thanks,
-Chris
-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Tuesday, April 29, 2008 04:22
To: Chris Holmes
Cc: Christopher Condit; geoserver-users@lists.sourceforge.net; Justin
Deoliveira
Subject: Re: [Geoserver-users] getfeatureinfo and coverages
Chris Holmes ha scritto:
What I believe to be a bit more of the 'correct' way to get feature
and
coverage data is to use the appropriate OGC service, WFS for vector
and
WCS for raster. GetFeatureInfo is a bit funky with things like the
html
output, since it depends on the server rendering it some way that's
never standard. So I think the more interoperable way is to get at
the
data directly, and choose on the client side how to style it.
Of course I concede it's nice for the server side to apply styles, it
can make things easier for. But yeah, the uber correct way would be
to
do a WCS GetCoverage call to get the raster values, which gives you a
lot of control over how to request it, and then on the client use some
javascript to insert it in to the right html elements to make it look
the way you want.
There's a catch thought... WCS does not support any output that a
javascript client could parse (not structured output text formats).
So I guess for the moment adding customization to the GetFeatureInfo
template is the easiest way. What you get now is that the "bands"
making up the image are faked up as attributes of a feature, this
is to leverage the existing infrastructure but also because
it's the most sensible "what's there" answer for a coverage.
Works especially well for DEM like coverages, of course getting
an answer that tells you the RGB components of a true color image
is not very useful but... if the coverage is a true color one,
what would you expect?
What we're really missing in GetFeatureInfo is a JSON output imho
that would allow javascript clients to do whatever they please
with the output. But there's a catch, that wouldn't be portable
across OGC servers. Well, of course Christofer can use the GML2
output of GetFeatureInfo instead, that's one of the formats suggested
by the standard (and one of the reasons we have to turn Coverage
feature info into a fake feature, since that's the only
thing that is encodable into GML2 at the moment).
Digressions aside, Christofer, I'm wondering what you really need.
If you just need to provide a different presentation for the
"band values" then a fix in the template subsystem is all you
need -> open a jira issue asking for that at jira.codehaus.org.
Cheers
Andrea