Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit : > Even, > Thanks for your quick response. > > I believe I understand that three options you presented me. I believe > option 1 is viable but like you mentioned will only work with GDAL > software. Options 2 and 3 are good but, especially with option 3, the > resulting tifs are too large. > > I have 20 .tif which are 3MB a piece. Together, they form trackline of a > sensor data. I would like to load this information into a WMS server for > display in Google Earth or Arc Explorer. Currently I am using Geoserver. > > Anyways, I must mosaic these 20 .tifs together. These tifs are indexed > images with a colormap. Here is my current algorithm: > 1. Expand images to RGBA using gdal_translate > 2. Rotate images north up using gdal_warp > 3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1 -ot > Byte -co TILED=YES -n 0 > At this point, I now have an RGBA image that is huge (300MB). With all the > tile collections I must process, 300MB is too big. I was thinking the > total would be around (20 tiles)*(3MB per tile) = 60MB. 300 is simply > unacceptable. > 4. Run the gdal_retile to make image pyramid. This will yeild a size that > is roughly twice that of my mosiac. > > Is there any way I can make the RGBA file in step 3 smaller in size > specifically to match the theoretical size of 60MB?
You can try rgb2pct.py on the mosaic Or you can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since I'm not sure how efficient the compression done by gdal_merge will be. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
