From: Andrea A. <and...@al...> - 2004-04-12 09:10:31
|
On Monday 12 April 2004 08:43, Alvaro Zabala wrote: > Hi! > > > > Rendering would be deppendent of MapLayer implementation. > > > >No, the MapLayer does not renderer, it's just a model. The actual > > rendering is done by LiteRenderer or the j2d.Renderer class. > > Agree with you, what i wanted to mean is that Renderers has the knowledge > about rendering Layers. You call Renderer#render(Layer) and internal code > distincts CoverageLayer from FeatureLayers. > > What time is your weekly IRC meeting? Im introducing at GeoTools know and I > dont know your protocols... (Ill read it at Geotools page). This evening at 19.30 UTC, look up your local time here: http://www.timeanddate.com/worldclock/fixedtime.html?day=12&month=4&year=2004&hour=19&min=30&sec=0&p1=0 > > > 2) We get the fragment of the image (BufferedImage for desired > > > Envelope) > > > >This means that you can mimic tiling. > > Not exactly. We get a whole BufferedImage to return it. But yes, we could > mimic tiling with this approach. The problem is that JNCSFile (Ecw codec of > ER-Mapper) internally uses image pyramids. We cant know of what pyramid > level we are getting an image fragment. Thats the reason why we decided to > not make complex code with these issues. Why? You can't just ask for native resolution, width and height, decide on a reasonable partitioning, and then ask for "tiles" as subimages at native resolution? > >>One thing I don't > > > >understand: are you using the multiresolution support or not? As far as > >things > >goes now Geotools does not support multiresolution images since none of > > the data sources we are dealing with has built-in multiresolution > > efficient data extraction. > > JNCSFiile uses it internally. We cant control it. We call setView and get > image data (we cant know what is the resolution level used by JNCSFile) No way to get the native resolution huh? That's really weird. > But we are using multiresolution with JAI. How? First of all, we create an > image pyramid with JAI (bath scripts that load an image and generate images > with 1/2 size ratio) > After that, we have separated Image from its DataSource. All our images > have a DAO object (ImageDataAccesor). One implementation is > PyramidImageDataAccesor. It has a collection of ImageDataAccesor (same > images of different resolutions). When we call to > getBufferedImage(Envelope envelope, int w, int h) method, it computes image > resolution of the desired image. After that, it look for the > ImageDataAccesor whose Image has the best resolution (close to desired > Image resolution), and call to getBufferedImage of this ImageDataAccesor. Well, the main problem I see here is that GridCoverage is thought as a layer to perform computation on, so it's not multi-resolution and not optimized for visualization, whilst you architecture matches ECW support for fast viewing. It means that the rendereres should know that this is an ECW image and treat it especially. Moreover, we can't use the GridCoverage class I fear... Martin should know better than me about it (he is the one who created the GridCoverage class) > I think we would be interested in work in this with GeoTools. Well, we certainly accept any kind of contribution, the main problem with many of our developers is cronic lack of time. I'm answering you today just because I'm still on holiday (today is a holiday in Italy, we call it the Angel's Monday). Best regards Andrea Aime |