[fdo-internals] New RFC10 Is Posted

[Maggie Yang]

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.

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.

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 10:27 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] New RFC10 Is Posted

Maggie Yang wrote:
> Hi, All
> 
> A new RFC (http://trac.osgeo.org/fdo/wiki/FDORfc10 ) has been posted. 
> The RFC addressed changes in WMS override API in order to support 
> additional parameters and bit depth variants.
> 
>  
> 
> Please review the RFC. Any comments/suggestions and questions are 
> welcome. All feedback is expected by the end of Sep 14^th , 2007. If
no 
> changes are required it is my intent to motion that a vote for the 
> acceptance of the RFC be made and subsequently voted on by the PSCs.

Maggie,

I'm wondering why the WMS provider is limited to the four listed
formats.
I can see quite valid reasons why someone might want to get results back
in jpeg2000 format if that is supported by the wms server for instance.

Is GDAL being used to read the results within the WMS provider?

In general I agree with the image format being made more general, and I
have myself deployed wms servers in the past that offered multiple
variations of PNG or TIFF format for instance.

BTW, it isn't absolutely clear to me that we should require RFCs for
extensions to single providers.  This RFC doesn't change the FDO data
model or API in any way, right?   It is just a change in interfaces
internal
to the WMS provider, and to the externally visible configuration
document?

In my (not so humble) opinion a pure extension (not disruptive) change
like this could be made after notifying the fdo-internals list of the
plan
rather than needing to go through the full RFC process.  Perhaps Greg or
others have an opinion on this?

For instance, I added bounds-in-config-xml support to the GDAL provider
without an RFC, though in that case there was the model of the ATIL
based
provider to follow.

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