[fdo-internals] New RFC10 Is Posted

Maggie Yang maggie.yang at autodesk.com
Tue Sep 11 02:04:55 EDT 2007

Hi, Frank

I understand your consideration. We will support more image formats
which are widely-used by WMS server in the future. But this time, we are
mainly focusing on the additional parameters, still limiting the image
format to the most common used type in order to make sure the quality,
because it will increase the QA work load to test all possible image
format in such short time.

The user can access LayerDefintion, ClassDefintion,
PhysicalSchemaMapping and etc via WMS Override API, which is published
API. For example, user can create the physical mapping via those API.

Maggie Yang

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Thursday, September 06, 2007 9:58 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] New RFC10 Is Posted

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
> extend the supported image formats. The old WMS provider only
> 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
> server.
> Could you send one or some WMS URL(s) which supported Jpeg2000? We can
> try it.


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
> 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
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
<Format> element of the configuration file, and some internal provider

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,

fdo-internals mailing list
fdo-internals at lists.osgeo.org

More information about the fdo-internals mailing list