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
Hi,
I think there is a bug in gdalinfo, I already noticed this kind of
problem, for example
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-corner-coords-in-tif-vs-ecw-td5608144.html
You should file a bug at http://trac.osgeo.org/gdal/ .
Jean-Claude
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,
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
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
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
Hello,
I am trying to use WMS to obtain some elevation data from the USGS seamless
server. I use the following syntax:
gdalinfo WMS:
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
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
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
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
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
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
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
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 alexmant...@suremptec.com.ar
Antonio:
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 a
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
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 alexmant...@suremptec.com.ar
I tried the patch warmerdam posted on
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 greenb...@ucdavis.eduwrote:
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
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
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
21 matches
Mail list logo
