[gdal-dev] Motion: Adopt RFC45 : GDAL datasets and raster bands as virtual memory mapping
Motion : I move to adopt RFC 45 (GDAL datasets and raster bands as virtual memory mapping) http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Starting with my +1 Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] White lines in merged GeoTIFF files
Dear list, I have merged 21 GeoTIFF images using GDAL utilities. Each image is the result of merging 500 smaller tiles. I am using ImageMosaic in Geoserver but I am getting a mosaic that contains white lines What could be the reason behind having those white lines? The commands that I used are: (recommended by Jonathan Mule on Geoserver mailing list) gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Thank you in advance //Ammar ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC45 : GDAL datasets and raster bands as virtual memory mapping
+1 On Sun, Jan 12, 2014 at 5:03 AM, Even Rouault even.roua...@mines-paris.orgwrote: Motion : I move to adopt RFC 45 (GDAL datasets and raster bands as virtual memory mapping) http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Starting with my +1 Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Color Columns in Raster Attribute Tables
Hi List, There appears to be an inconsistency in the way color columns are handled within Raster Attribute Tables (RATs) by different drivers. Color columns are currently identified by their 'usage' setting - GFU_Red, GFU_Green, GFU_Blue and GFU_Alpha. The HFA driver presents color columns as doubles between 0 and 1 as this is how they are stored in the file. The IDRISI driver presents them as integers between 0 and 255 like the Color Table API. Code that uses color columns from the RAT API currently needs to know which driver it is using, defeating one of the aims of GDAL. I propose that the RAT API be defined so that color columns always appear as Integer 0-255 no matter what type and range they are stored as. This would make the RAT API consistent with the Color Table API and would mean a change to the HFA driver Another option is that flags are added to the RAT SetValue, GetValueAs* and ValuesIO calls to specify the conversion to/from the native type. This seems a bigger change. Any thoughts? Sam. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Color Columns in Raster Attribute Tables
Hi Sam, In GDAL color table is supported by the GDALColorTable http://gdal.org/classGDALColorTable.html not by GDALRasterAttributeTable http://gdal.org/classGDALRasterAttributeTable.html. The GDALColorTable is a little bit limited but it is pretty much consistent across all the drivers that support it. For example, when you say that HFA reports RGBA with values from 0..1 as RAT it probably reports the correct 0..255 as GDALGetColorTable or it doesn't report it at all, because of the GDALColorTable limitation, like data type or number of colors. But IMHO, there is no reason to expect consistency on the representation of color table from a driver RAT. An RAT could be user defined or generated by some driver or application. What you are seem is that some drivers are using, or maybe abusing, the freedom format of RAT to report information than can be understood by some particular application or software (mea culpa on one of those). Best regards, Ivan Date: Mon, 13 Jan 2014 13:06:01 +1300 From: gillingham@gmail.com To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Color Columns in Raster Attribute Tables Hi List, There appears to be an inconsistency in the way color columns are handled within Raster Attribute Tables (RATs) by different drivers. Color columns are currently identified by their 'usage' setting - GFU_Red, GFU_Green, GFU_Blue and GFU_Alpha. The HFA driver presents color columns as doubles between 0 and 1 as this is how they are stored in the file. The IDRISI driver presents them as integers between 0 and 255 like the Color Table API. Code that uses color columns from the RAT API currently needs to know which driver it is using, defeating one of the aims of GDAL. I propose that the RAT API be defined so that color columns always appear as Integer 0-255 no matter what type and range they are stored as. This would make the RAT API consistent with the Color Table API and would mean a change to the HFA driver Another option is that flags are added to the RAT SetValue, GetValueAs* and ValuesIO calls to specify the conversion to/from the native type. This seems a bigger change. Any thoughts? Sam. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
