[fdo-internals] RE: Re-Openeing FDO RFC 10

[Greg Boone]

>> 1) I am wondering why we will use default value: PNG when there is no valid interpretation.

[GB] I agree that we should only allow the user to set the 'known' formats that work. An exception is reasonable.

>> 2) How should we handle the following situation, when we parse a configuration file like below:
         <RasterDefinition name="Image">
          <Format>TIFF</Format>
          <FormatType>image/png;PhotometricInterpretation=PaletteColor</Format>
        ...
        </RasterDefinition>

[GB] In this case, the WMS 3.3 Provider should ignore Format and just use FormatType. For 3.3, <Format> is deprecated.


[GB] NOTE: The updated version of RFC 10 has not yet been accepted. Can you validate the behavior on both Map 2008, Map 2009 (Development Version) and MapGuide 1.2, to determine if there are any side effects associated with the change?

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maggie Yang
Sent: Thursday, October 25, 2007 12:49 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Re-Openeing FDO RFC 10

Hi, Greg

You have written:
For the 3.3 FDO WMS configuration API,

Calls to

        void SetImageFormat(FdoString* value);

would result in the generation of XML content that contained both <Format> and <FormatType>

        <RasterDefinition name="Image">
          <Format>PNG</Format>
          <FormatType>image/png;PhotometricInterpretation=PaletteColor</Format>
        ...
        </RasterDefinition>

where the content of <FormatType> is the content passed through the call to SetImageFormat() and the content of <Format> is interpreted and set form the allowed values of <FormatType>, with a default value of PNG being used no valid interpretation can be made.

I have following considerations:
1) I am wondering why we will use default value: PNG when there is no valid interpretation.
For example, when calling like below:
        SetImageFormat(L"image/BMP; mode=24bit");
Or
        SetImageFormat(L"BMP");
I think we should throw exception, which notify the caller "BMP" is not a valid XML Raster Format Type, since WMS only support 4 type image formats.
2) How should we handle the following situation, when we parse a configuration file like below:
         <RasterDefinition name="Image">
          <Format>TIFF</Format>
          <FormatType>image/png;PhotometricInterpretation=PaletteColor</Format>
        ...
        </RasterDefinition>
Throw exception to conflicted setting or just parse <FormatType> and ignoring the <Format>.

Thanks,
Maggie Yang

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Wednesday, October 24, 2007 1:26 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: Re-Openeing FDO RFC 10

(Re-formatted for plain text....)


Hi All,

It looks as if we will have to revisit RFC 10: 'Modify WMS override API to support additional parameters and bit depth variations'

http://trac.osgeo.org/fdo/wiki/FDORfc10

The RFC as defined and implemented is not forwards compatible with Autodesk Map 3D 2008. Testing using that platform resulted in an unexpected exception and the failure of the application.

Here is the WMS Configuration File content that identifies the content change that causes the exception:

Map 3D 2008

        <RasterDefinition name="Image">
          <Format>PNG</Format>
        ...
        </RasterDefinition>

Map 3D 2009 (Development Version)

        <RasterDefinition name="Image">
          <Format>image/png; mode=24bit</Format>
        ...
        </RasterDefinition>

Map 3D 2008 is unable to decipher the appended text: 'mode=24bit', or any other variation of the WMS format type.

** Here is the proposed solution I have in mind to resolve the issue **

Revert the content change to <Format> element made in 3.3 and continue to write the value of the <Format> element as was previously done in 3.2.2. This would allow continued compatibility with applications written for 3.2.2. At the same time the FDO 3.3 WMS provider configuration file would be modified to contain a new <FormatType> element that would only be evaluated by the 3.3 version of the WMS provider and subsequent releases. FDO 3.3 would look for <FormatType> first and if not found evaluate <Format>. FDO 3.2.2 would continue to evaluate <Format>  and ignore <FormatType>. There would some duplication of information, but applications written on both versions of the WMS Provider should continue to work as designed. The <Format> would be deemed deprecated and removed once forward compatibility support is no longer required.

The resulting 3.3 WMS configuration xml document would take the form of...

<RasterDefinition name="Image">
  <Format>PNG</Format> // Deprecated element. This one is consistent with FDO 3.2.2
  <FormatType>image/png;PhotometricInterpretation=PaletteColor</FormatType>
...
</RasterDefinition>

-----------

For the 3.2.2 FDO WMS configuration API....

Calls to

        void FdoWmsOvRasterDefinition::SetFormatType(FdoWmsOvFormatType value);

would continue to result in the generation of XML content that contained only the FORMAT element as follows

        <RasterDefinition name="Image">
          <Format>PNG</Format>
        ...
        </RasterDefinition>

Calls to

        FdoWmsOvFormatType FdoWmsOvRasterDefinition::GetFormatType(void) const;

would continue to result in the return of the expected FdoWmsOvFormatType enumeration type

----------

For the 3.3 FDO WMS configuration API,

Calls to

        void SetImageFormat(FdoString* value);

would result in the generation of XML content that contained both <Format> and <FormatType>

        <RasterDefinition name="Image">
          <Format>PNG</Format>
          <FormatType>image/png;PhotometricInterpretation=PaletteColor</Format>
        ...
        </RasterDefinition>

where the content of <FormatType> is the content passed through the call to SetImageFormat() and the content of <Format> is interpreted and set form the allowed values of <FormatType>, with a default value of PNG being used no valid interpretation can be made.

Calls to

        FdoString* GetImageFormat(void) const;

would result in the return of the expected string set through the call to SetImageFormat() and/or the value contained in the <FormatType> element. The content in <Format> would not be returned or evaluated.

---------

NOTE: There was some consideration to creating a separate XML element to contain the additional type information that would work in conjunction with <Format>, thus preventing the need to deprecate it. This idea was considered but rejected due to the belief that it would be improper to separate an arbitrary server defined string value into 2 FDO XML string configuration elements and expect the application or provider to be able to determine how the strings should be concatenated to form a valid request to the WMS server. There is no set standard on how the server would return the format type strings as XML in the WMS server capabilities response document, so it is best to maintain the string as returned the server as a single entity.

Thoughts/Ideas/Feedback?

Regards,

Greg


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