| Re: [udig-devel] GeoTiff fast render |
On Friday, 1 April 2011 at 9:18 PM, Devrim Baris Acar wrote:
Hi,
Apart from Jody's recommendations I would also try adding overviews to the geotiff images, use gdal_addo from gdal tools for this purpose.
Another option would be to setup a geoserver instance and build pyramids. That will also speed up a lot, I am serving 30x78 mb geotiffs with this option.
Just my 2 cents,
Devrim Baris Acar
On Fri, Apr 1, 2011 at 12:00, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:We have a tiling cache for working with tile servers (all kinds of tile servers). You can configure it to work on disk or memory.There is some low level control of the Java Advanced Imagining tile cache used for rendering raster; I was talking to about this a month ago with Rueben (but we have not made the preferences available to users).Hi Ruben:I have a couple of suggestions; mostly around how JAI and its internal "image cache" is used.I am really not keen on the "InMemoryCoverageLoader" code; as it represents us "fixing" a problem in the wrong manner. The trouble is we have not done the experiments to sort out what the correct manner is.JAI makes use of a tile cache which it uses when working with raster data; and it does a pretty good job of not regenerating content it already has sorted out once. In uDig 1.1.x we did not actually use the tile cache at all; in uDig 1.2.0 I have tried storing a tile cache for each layer. While this is good in that we don't throw out our work each time we render it is bad as we do not use memory in a very wise fashion.What we really should do is store a tile cache ...- for each map (ie on the map blackboard?) this would allow a good balance between all the raster in use for the map; and we could "empty" the cache if the map was closed ...- for each workbench window as Eclipse workbench service (like selection service) - which amounts to a blackboard for each eclipse window open. This would allow a larger bucket of memory to be devoted to raster use; and as we change between maps and so on JAI would be able to figure out what tiles were stale etc...As for geotiff; there should be a fair bit that can be done. But 1st I need to ask how the image is slow?!) is it slow when looking at the entire image zoomed out?- If so an overlay would do wonders- or ask JAI to create an overlay in memory when the image is 1st loaded? It would smoothly switch from the overlay to the real data when zooming in.- or create an overlay as part of your geotiff file itself; it is the fastest way to help the performance (and no code changes)2) is it slow when zoomed in?- the JAI image tile cache things mentioned above should help; try different values (maybe make a preference page so users can try different values)- go to an internal tile system in your geotiff (cannot remember what the option is called). It would prevent the disk head from running all over the place as it reads in a zoomed in "tile" of information.- experiment with JAI title cache and geotiff internal timing (perhaps getting the two sizes to line up; or auto configuring the jai tile cache based on the tiles in your geotiff would do something?)But yeah the number one advice here is to please chech that we are using the JAI tile cache; rather than something horrible like loading the image into memory ourself. If we have to set up the JAI tile cache and load the image into that it would be much better.You can go into the code and update the settings internally and try the different options.
--
Jody GarnettOn Friday, 1 April 2011 at 5:31 PM, Juho Kokkonen wrote:
Hi
Thanks Jody for your answer.
I have just one more question. Udig has an tiling cache right? is that cache only on raster image? not for shapes?
Mayby i misunderstanding something but i'm quit sure that i have been read that udig
has been remove shapefilerenderer on 1.2 version. am i right?
Regaards
Kokkonen_______________________________________________Perhaps you can try prepairing your data; a simple solution would be to dump
them all into a single folder and use the image moasic wizard. It should
create a shapefile listing each file; and use that shapefile as an index to
help with performance.
Other than that you should consider the tradeoff of disk speed / cpu power
when preparing your data for any purpose. Including display as a background
layer in uDig.
There is also a lot you can do with the format of the image, in addition to
the compression, internal tiling you mention uDig also responds well to
overlays.
--
Jody Garnett
On Friday, 1 April 2011 at 7:25 AM, Juho Kokkonen wrote:of them (about 20 geotiff files). Each file has an size of 30mb. So this wayHi
I have a tricky situation. I use geotiff files on my udig and i have a lot
i've got 20 layers on my udig software.one by one back (yes i now udig use each layer a own render thread). well
Well if i zoom or pan a map all my layers disappear to map and then comes
because my layers are a big and they are a many this is a slow oparation and
causes a lot of white screen each pan or zoom.udig is powerfull gis toolkit.
So i was wondering that what i do wrong because i have understand that
Do i have to handling my geotiff pictures like compress or tiling?
Do i have to create own renderer of them?
Or do i have to use some software to creating a one gigant big shp file?
So i can use shapefilerenderer? and how i use it?
I hope u guys getting my idea and could help me!
Thanks
Kokkonen
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel