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

[Greg Boone]

(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