Martin Desruisseaux <[EMAIL PROTECTED]> wrote on 12/15/2006 09:35:20 PM:
> Bryce L Nordgren a écrit : > > Item 1: "Geophysics" and stored portrayal > > The 19123 coverage data type is not responsible for maintaining a > > "rendered" version of itself. The "geophysics" flag is likely to > > disappear. There is separate work with imagery. (19128/19130). If you've > > rendered a coverage to an image, it should be a completely separate > > coverage. We can define an "ImageCoverage" data type which maintains an > > optional reference to a "base" coverage which contains the actual data. > > Just a precision: the "geophysics" stuff do not come from any OGC or ISO > standard; it is a pure Geotools extension. We need some way to switch between > "image" and "geophysics" views, however we can do that in a > different way than > what we currently do if there is better idea. The minimum impact approach is to just advertise what you got. If your coverage is a color image, your RecordType should contain Red, Green, and Blue fields. If your coverage is temperatures, it should have one field called "Temperature". The renderer should be capable of merging the coverage data with a color model appropriate to the particular image framework, thus producing a rendered picture. To maintain good separation of concerns, we _do_not_ want coverages in charge of their own rendering. We also _do_not_ want to only be capable of rendering coverages implemented by us (although if it _is_ ours, we can optimize). Now, what if we hand off the "Temperature" coverage to a renderer and receive an image which is a pixel-for-pixel coloration of the scene? Perhaps our RecordType could contain "Red", "Green", "Blue" and "Temperature". The "switching" you mention occurs when the user evaluate()s the coverage. Users are permitted to request that only certain fields be returned. If they want the source data, they look for "Temperature". If they want image data, they request for "Red", "Green", and "Blue". The ImageCoverage could generate the image on the fly rather than cacheing it. This would allow it to do something intelligent: like interpolate the temperature to the requested point, then apply the color model to that temperature; rather than interpolate the red, green, and blue bands separately. > > Item 2: GT Grid Implementations > > 19123 defines a Grid abstraction which is used by three coverage types. GT > > should definately offer a Grid implementation based on the standard J2SE > > image objects (2 spatial dimensions + no temporal dimensions + bands; or 2 > > spatial dimensions + band axis is temporal). For multidimensional > > coverages, I propose that GT offer a Grid implementation based on the > > Multiarray2 library distributed with Java NetCDF. > > This is one approach. It probably has the advantage of working directly with > NetCDF files. An other approach is "CoverageStack", which is already > implemented > and will probably stay usefull in some cases. I guess that both > implementations > can live together. That's the beauty of interfaces. :) The other advantage of multiarray2 is that there is one data buffer and one indexer for the entire stack. ;) > > Item 3: GT Coverage Implementations > > I propose we start with the discrete grid point coverage, as this is the > > simplest item with the greatest utility. I propose that the second focus > > of implementation is continuous quadrilateral grid coverage. The > > continuous coverage _implementation_ should probably be related to the > > discrete coverage _implementation_, and should only add the ability to > > interpolate. I do not see an advantage to making a "special" 2D discrete > > coverage. I do think it is worthwhile to supply a "special" 2D continuous > > coverage which leverages the current JAI infrastructure to interpolate. > > But a discrete coverage backed by a RenderedImage would be a "special" 2D > discrete coverage, no? If yes, then the proposed plan is basically a > refactoring > of GridCoverage2D and Interpolator2D, which I agree with. Basically we're in agreement. I think, though, that much of the J2SE image stuff could be a specific implementation of the Grid abstraction. Discrete grid point coverage then leverages a "Grid" to fulfill the coverage interface contract, but doesn't need to know any j2se specifics. That's what I meant when I said "discrete grid point coverage" doesn't need to be specially written for J2SE images. THat implementation specific stuff should be hidden by Grid (and by the GridCellValue object). Bryce ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
