[fdo-internals] New RFC10 Is Posted

[Frank Warmerdam]

Maggie Yang wrote:
> I think support jpeg2000 is a good idea, we maybe can make it in near
> future. But in this RFC, which is mainly focusing to extend the
> additional parameters and bit depth variants. So, we did not consider to
> extend the supported image formats. The old WMS provider only supported
> those 4 images formats: image/png, image/jpg, image/tif, image/gif,
> because those 4 are the most common-used image formats by WMS server.
> We can consider to supported Jpeg2000 if this one is widely-used by WMS
> server.
> Could you send one or some WMS URL(s) which supported Jpeg2000? We can
> try it.

Maggie,

Well, JPEG2000 was just intended as an example.  My core question is
why limit the format selection?  Why not let the user try anything, and
if it turns out to be not supported by the available GDAL build then
error out gracefully at that point.

> Correct, WMS provider use GDAL to parse the data.
> 
> This RFC will change the WMS provider API, because the interface changes
> from enum to string type. So, we need to require a RFC.
> Thanks for your reminder, I will make this point clear in the RFC
> document.

Ah good point.  I hadn't considered that disruptive aspect. Actually,
reading your updated RFC I see the configuration file is still backward
compatible so that is good.

You mention the provider API, but applications don't actually ever access
the WMS provider specific API do they?  Isn't this just for internal use
within the implementation of the provider?

As I read the RFC right now, it is just loosening the values allowed in the
<Format> element of the configuration file, and some internal provider
changes.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org