Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

Jonathan you can do scaling on individual bands. gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile outfile1.vrt gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile outfile2.vrt gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile outfile3.vrt gdalbuildvrt -separate output.vrt

Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

Nikos and GDALers: This is CLOSE to what I'm looking to do, but I'm having a hard time getting it working properly. Here's my input dataset gdalinfo dump: *** Driver: ENVI/ENVI .hdr Labelled Files: 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi 10SEP10191223-M2AS-052377832030_0

Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

why you don't try rgb2pct http://www.gdal.org/rgb2pct.html? --Nikos Hatzopoulos On Wed, Jun 8, 2011 at 2:20 PM, Jonathan Greenberg wrote: > Folks: > > I am using a piece of software which is relying on an older version of GDAL > that doesn't have the "fix" to deal with > 8 bit geotiffs (it is tr

Re: [gdal-dev] HDF5 COSMO-SKYMED metadata problems

Sorry, I accidentalñy pressed the "send" button Another issue. Does anybody has the COSMO-SKYMED HDF5 format specification or something that tells how to get the georreference information from those files? 2011/6/8 Alex Mantaut > I tried the patch warmerdam posted on the 1.8.0 version an it w

[gdal-dev] installing ogrsf_frmts include files

Hi Frank et al, Is there a way to install the ogrsf_frmts include files short of just manually copy the files. OpenGraphRouter is using some of these in C++ to create geometries. Specifically: ogrsf_frmts/shape/shapefil.h ogrsf_frmts/kml/ogr_kml.h and maybe some others. Since these are n

[gdal-dev] Converting from 16 bit to 8 bit images (best practices?)

Folks: I am using a piece of software which is relying on an older version of GDAL that doesn't have the "fix" to deal with > 8 bit geotiffs (it is trying to make a jpeg overlay but can't from a 16 bit image. I think this is the issue: http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG), but when I do

Re: [gdal-dev] HDF5 COSMO-SKYMED metadata problems

I tried the patch warmerdam posted on the 1.8.0 version an it worked, i can see the root metadata now. Thanks Antonio Valentino and Frank Warmerdam for the swift correction. Another issue. Does anybody has the COSMO-SKYMED HDF5 2011/6/7 Alex Mantaut > Antonio: >Thanks for the swif

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

On 06/08/11 19:36, Armin Burger wrote: thanks for pointing me to the ECW definitions. My main problem are currently the missing ETRS89/GRS80 definitions for several pan-European projections that are missing. Some national projections I need I could already identify and I will try them. If a proje

[gdal-dev] RE: Adding jasper support to gdal build

I was finally able to get this to build, but I had to run configure of gdal with the --without-libtool option. What kind of affect does this have on the software (other than having a successful, shorter build)? I still dont quite understand what the cause was. This has enabled me to read JPEG2

Re: [gdal-dev] gdalwarp: ERROR 2: Out of memory allocating {number} byte destination buffer.

Hi Frank, Thanks for the clear explanation. I've added, with light editing, to http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp. I imagine you will just have to use more modest buffers or else get a 64bit executable for gdalwarp. Running gdalwarp with defaults (no options specified) seems

[gdal-dev] Adding jasper support to gdal build

Hello all, i am trying to add jasper support to gdal so I can read jpeg2000 in NITF files. I downloaded the version of jasper off the site, and configured it like so: ./configure --enable-shared --prefix=/home/dcole/dump/jasper-1.900.1.uuid make make install which created bin and lib folder

Re: [gdal-dev] gdalwarp: ERROR 2: Out of memory allocating {number} byte destination buffer.

On 11-06-08 03:05 PM, Matt Wilkie wrote: Hi Folks, Can anyone tell me what this error means and how to work around it? Win7 x64 command shell osgeo4w gdal 1.8 13gb ram (~4.7gb free according to Process Explorer) 121gb free on the drive (mapped to network) 20gb free on drive pointed to by %TEMP%

Re: [gdal-dev] gdalwarp: ERROR 2: Out of memory allocating {number} byte destination buffer.

Hey Matt, If i remember correctly osgeo4w is 32bit (its been a while since iv looked at the osgeo4w binaries however so i may be incorrect). If they are 32bit and you are setting -wm to 2048 (2GB) you might be having memory limitation issues (which i believe 2GB virtual memory for x86 exe

[gdal-dev] gdalwarp: ERROR 2: Out of memory allocating {number} byte destination buffer.

Hi Folks, Can anyone tell me what this error means and how to work around it? Win7 x64 command shell osgeo4w gdal 1.8 13gb ram (~4.7gb free according to Process Explorer) 121gb free on the drive (mapped to network) 20gb free on drive pointed to by %TEMP% There are 26 input files whose size rang

[gdal-dev] WMS Psuedo GetMap Request and image resolution

Hello, I am trying to use WMS to obtain some elevation data from the USGS seamless server. I use the following syntax: gdalinfo "WMS: > http://imselev.cr.usgs.gov:80/wmsconnector/com.esri.wms.Esrimap/USGS_EDC_Elev_NED?REQUEST=GetMap&VERSION=1.1.0&LAYERS=NED.CONUS_NED&SRS=EPSG:4326&FORMAT=image/ti

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

Frank, Jean-Claude, thanks for pointing me to the ECW definitions. My main problem are currently the missing ETRS89/GRS80 definitions for several pan-European projections that are missing. Some national projections I need I could already identify and I will try them. If a projection is missing

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

Le 08/06/2011 17:30, Armin Burger a écrit : I found on my Windows installation a file "PcskeyProjDatum.dat" with a few definitions of projection and datum used but this was very limited and covered mainly UTM and NAD. Most European projections and datums were missing in this file. The datum a

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

On 11-06-08 11:30 AM, Armin Burger wrote: Jean-Claude I guess it's not only a problem of gdalinfo but of some parts of GDAL in general dealing with the ECW. I made some more tests and when I add the options -co DATUM=WGS84 -co PROJ=NUTM32 to the gdal_translate call then gdalinfo identifies

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

Jean-Claude I guess it's not only a problem of gdalinfo but of some parts of GDAL in general dealing with the ECW. I made some more tests and when I add the options -co DATUM=WGS84 -co PROJ=NUTM32 to the gdal_translate call then gdalinfo identifies the coordinates correctly afterwards, b

Re: [gdal-dev] gdal_translate - ECW format and non-UTM projections

Hi, I think there is a bug in gdalinfo, I already noticed this kind of problem, for example You should file a bug at . Jean-Claude __

[gdal-dev] gdal_translate - ECW format and non-UTM projections

Hi all I am using "gdal_translate" to convert GeoTiff or Erdas images to ECW. This works fine when using standard projections like UTM-WGS84. For UTM I guess GDAL even writes the correct projection information into the ECW header. Several problems appear however if I convert images that are in