Le jeudi 02 juin 2011 20:28:42, Andrés Maneiro a écrit : > Thanks Even for the response, I suppose it has to do with your > suggestions, but I don't know why, as I don't see any compression > algorithm within gdalinfo output :/
ok, so it is well NBITS = 1 and actually uncompressed, and with 64x64 tiles. So try : gdal_translate -a_srs "EPSG:23029" original.tif output.tif -co NBITS=1 -co TILED=YES -co BLOCKXSIZE=64 -co BLOCKYSIZE=64 output.tif should have a similar size to original.tif > > Here the output of gdalinfo on the original tiff: > > Driver: GTiff/GeoTIFF > Files: 120135.tif > Size is 12261, 9595 > Coordinate System is: > PROJCS["UTM Zone 29N", > GEOGCS["ED_1950_16", > DATUM["ED_1950_16", > SPHEROID["International 1909",6378388,297.0000535480247]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433]], > PROJECTION["Transverse_Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",-9], > PARAMETER["scale_factor",0.9996], > PARAMETER["false_easting",500000], > PARAMETER["false_northing",0], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]]] > Origin = (560152.010000000009313,4794483.370000000111759) > Pixel Size = (0.035418645400000,-0.035419541800000) > Metadata: > TIFFTAG_SOFTWARE=IMAGINE TIFF Support > Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved > @(#)$RCSfile: etif.c $ $Revision: 1.10.1.9.1.9.2.11 $ $Date: 2004/09/15 > 18:42:01EDT $ > TIFFTAG_XRESOLUTION=1 > TIFFTAG_YRESOLUTION=1 > TIFFTAG_RESOLUTIONUNIT=1 (unitless) > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( 560152.010, 4794483.370) ( 8d15'30.35"W, 43d17'59.98"N) > Lower Left ( 560152.010, 4794143.519) ( 8d15'30.49"W, 43d17'48.97"N) > Upper Right ( 560586.278, 4794483.370) ( 8d15'11.08"W, 43d17'59.86"N) > Lower Right ( 560586.278, 4794143.519) ( 8d15'11.22"W, 43d17'48.84"N) > Center ( 560369.144, 4794313.445) ( 8d15'20.78"W, 43d17'54.41"N) > Band 1 Block=64x64 Type=Byte, ColorInterp=Palette > Image Structure Metadata: > NBITS=1 > Color Table (RGB with 2 entries) > 0: 0,0,0,255 > 1: 255,255,255,255 > > On 02/06/11 20:07, Even Rouault wrote: > > Le jeudi 02 juin 2011 20:00:15, Andrés Maneiro a écrit : > >> Hello devs, > >> > >> I'm playing with GDAL to set the CRS of a set of geotiff files I was > >> given to upload them to geoserver later. > >> > >> These files, were generated using ArcGIS and it seems that the CRS set > >> in the geotiff file header is not standar (at least, my geoserver > >> > >> doesn't recognize them). What I did: > >> gdal_translate -a_srs "EPSG:23029" original.tif output.tif > >> > >> After doing that, the size of the output is 5/10 times bigger than input > >> (in some cases: from 10Mb to almost 110Mb). The only thing I see as > >> different -using gdalinfo on both files- is the "Color Table". The > >> former has 2 entries and the output has 256. Don't know if it's the > >> source of the problem, just let you know in case it is useful. > > > > Hum, it's likely that your original.tif was compressed. gdal_translate > > without argument will generate an uncompressed file. > > > > What is the output of gdalinfo on original.tif ? If you see a COMPRESS= > > metadata keywords, you can try reusing it as a creation option. > > > > It is also likely that your original.tif is a 1bit file. > > > > So, guess blindly, I would try : > > > > gdal_translate -a_srs "EPSG:23029" original.tif output.tif -co NBITS=1 > > -co COMPRESS=PACKBITS > > > >> So, my question is: how could I generate an output file, with CRS set > >> and with roughly the same size of the original? > >> > >> best, > >> amaneiro > >> _______________________________________________ > >> gdal-dev mailing list > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
