[Geoserver-devel] A tale of output formats (funny, but serious in the end)

Hi,
so I was trying to fix a WMS cite test failure Justin
reported me (bts, thanks a lot Justin for running the cite tests).

The issue was basically that the cite tests do expect the
output format to be the same as the content type declared in
the responses, and "rss" is not.

So ok, easy, just have to remove "rss" and "atom" from the output
formats. I also noticed that the list of format was not sorted
alphabetically, so while I was at it, I added sorting too.

Tried again and... bummer, spotted a bug in the cite test engine
I guess. The first output format became application/atom+xml,
and the cite engine was sending it unescaped to Geoserver, meaning
that url-decoding turned it into "application/atom xml". Bleah.

Righto... let's try reverse sorting the entries then, they are
easy to look at even in anti-alphabetical order no? No!
The first format became image/tiff8, which is in the form of
a mime type, but it's not the actual content type returned,
which is image/tiff! Bah! Then again, Simone added these to support
256 color images with clients that do not allow to tweak the request,
but only to choose the output format. We'll have to discuss
this. The WMS spec says the formats must be MIME types ...
Besides, png8, tiff8 are the only ways to get a 256 colors png and
tiff at the moment, we have no "palette=auto" support.

So, in the end I hacked the sorting an forced image/png to be the
first, and now all tests are passing... but I'm not so happy :wink:

Cheers
Andrea

Andrea Aime ha scritto:

Besides, png8, tiff8 are the only ways to get a 256 colors png and
tiff at the moment, we have no "palette=auto" support.

To clarify, I mean they are the only way to make Geoserver compute
the optimal palette, if you can provide one, or use the internet
safe palette, you can use palette=xxx along with image/png and
you'll get a paletted png (just like with png8).

Cheers
Andrea