Changes between Version 7 and Version 8 of FDORfc2

Timestamp:

Apr 18, 2007, 12:36:08 PM (17 years ago)

Author:

gregboone

Comment:

--

FDORfc2

@@ -174 +174 @@
 This API change is applicable for all raster formats.  For raster formats where the min/max cannot be deduced from the dataset, the provider should provide a mechanism to scan the image for min/max values if forced computation is requested.
 
-This ECO is being written in order to better support ongoing development using the FDO Raster providers. Existing customers such as AutoCAD Map and !MapGuide have implemented work-arounds to calculate the scaling range manually.
+This RFC is being written in order to better support ongoing development using the FDO Raster providers. Existing customers such as AutoCAD Map and !MapGuide have implemented work-arounds to calculate the scaling range manually.
 
 == Unresolved ==
-
-* It is questionable whether a method that can trigger a good deal of processing work belongs in a property oriented class like !FdoRasterDataModel.
 
 * When the raster data model bitsPerPixel is changed to 8, it is unclear how the provider is expected to convert the image to this number of bits per pixel.  Should it scale using the min/max described here?  Currently the FDO provider just truncates values outside the target pixel type range (as does the underlying GDAL RasterIO() API). 
@@ -184 +182 @@
 == Test Plan ==
 
-Raster Provider unit tests should be expanded to include usage of the new !MinMax Property
+Raster Provider unit tests should be expanded to include usage of the new !MinMaxValues Property
 
 == Impact of Not Implementing this ECO ==