[fdo-internals] New RFC10 Is Posted

[Maggie Yang]

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.


Thanks,
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
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

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals