Yes I can see a bit through it,
and I believe the most involved is getting Projection info through...
For a single output band with ncols(nXSize1) and nrows (nYSize1) in
Float32, I can generate an output.
hDataset[n_imgs] =
GDALCreate(hDriver[0],out,nXSize1,nYSize1,1,GDT_Float32,NULL);
But it is n
Shawn,
In the line where gdalinfo is linked, I see both :
-L/home/marinier/gcc-4.2.2-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
and
/usr/local/lib/libstdc++.so
That looks like a possible mix of libstdc++ versions...
To make some progress by yourself, I think you should really proceed
step-b
And even if your input and output datasets are scanline oriented, you are
using a VRT as an intermediate, and VRT has blocks of size 128x128...
Le Monday 24 November 2008 23:10:13 Frank Warmerdam, vous avez écrit :
> Tom V. wrote:
> > Hi,
> >
> > I'm using gdal 1.4.2 to write out NITF and GeoTiff
Hello,
I'm following up on this mail from a few months ago:
http://lists.osgeo.org/pipermail/gdal-dev/2008-June/017358.html
Have there been any patches or workarounds for this issue? I'm using a
collection .dem files that mix feet & meters, and I can't see any
other way to access the
Tom V. wrote:
Hi,
I'm using gdal 1.4.2 to write out NITF and GeoTiff images. The
createCopy() call takes only a few minutes to write out a small file, 300
or so mb's, but takes anywhere from 1.5-3 hours to write out a single band
1.2 gb NITF or GeoTiff. I have not tried a larger multi-spectral
Just to mention that you could have kept hdf5 as it is unrelated to the
netcdf / hdf4 issue
Le Monday 24 November 2008 20:57:51 Roger André, vous avez écrit :
> Sorry, should have trolled the Web first. I see now that this is nothing
> new, and is caused by a conflict between libnetcdf and libhd
Hi Shawn,
I've never seen a NITF RADARSAT-2 image, so the RADARSAT-2 GDAL driver
was not designed to support NITF. Do you know if it's possible to get
some sample datasets in NITF format from somewhere?
At this point, if you want to read the NITF RS2 imagery, it's probably
safest to use the NITF
Hi,
I'm using gdal 1.4.2 to write out NITF and GeoTiff images. The
createCopy() call takes only a few minutes to write out a small file, 300
or so mb's, but takes anywhere from 1.5-3 hours to write out a single band
1.2 gb NITF or GeoTiff. I have not tried a larger multi-spectral image.
The cal
Thanks Frank.
I have tried to build on gdal 1.5.3 (w/o HDF) and overnight stable
branch. I got the same error message. But libgdal.so.1.12.3 was created
in gdal-1.5.3/.libs/
What is the problem?
/bin/sh /home/sgong/dev181/gdal-1.5.3/libtool --mode=compile
Hi list,
Does gdal (1.5.3 or 1.6 beta) support radarsat-2 SLC NITF format? I
believe it is a 64-bit complex NITF. if so, should I open the
product.xml or the imagery_HH.ntf?
thanks,
Shawn
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://l
Sorry, should have trolled the Web first. I see now that this is nothing
new, and is caused by a conflict between libnetcdf and libhdf4/5. I've
resolved this by doing the following:
1. Removing all hdf libs from my system:
$ sudo apt-get remove libhdf4g libhdf4g-dev libhdf5-serial-1.6.5-0
libhdf
Hi Roger,
Yes, this is a reccurent issue.
the way libhdf4g is built in Ubuntu (up to here... apparently a solution is in
Debian experimental, so it should change... after Lenny) is not compatible
with its use with netcdf. So you should either select one of both formats
when configuring GDAL, e
Hi everyone,
I'm having some problems getting gdal to read netCDF grid files using
gdal-1.5.2 which I have built from source. It is running on an Ubuntu 8.04
machine, and was built after the following dependencies were installed:
$ sudo apt-get install libnetcdf4 libnetcdf-dev netcdfg-dev ne
Yann Chemin wrote:
Hello,
I would like to use GDALCreateCopy and change the datatype from int32
to float32.
GDALDatasetH hDatasetOut0;
hDatasetOut0 = GDALCreateCopy( hDriver1, ndviF,
hDataset1,FALSE,NULL,NULL,NULL);
GDALRasterBandH hBandOu
Gong, Shawn (Contractor) wrote:
hi list,
I am building gdal 1.5.3 on Linux (RHEL).
I build the dependencies as follows (this was what I used for gdal 1.4.0):
1) glib 1.2.10
2) gtk+ 1.2.10 # stay with gtk 1.3 now, I plan to upgrade to
gtk 2 in near future
3) Mesa 5.0.2 (Mesalib on
hi list,
I am building gdal 1.5.3 on Linux (RHEL).
I build the dependencies as follows (this was what I used for gdal
1.4.0):
1) glib 1.2.10
2) gtk+ 1.2.10 # stay with gtk 1.3 now, I plan to upgrade to
gtk 2 in near future
3) Mesa 5.0.2 (Mesalib only, no demo, no glut)
4) gtkglarea-1.2
Hi Sjur,
I found out that in:
hDatasetOut0 = GDALCreateCopy( hDriver1, ndviF, hDataset1,FALSE,NULL,NULL,NULL);
the FALSE argument was there to inhibit strict identity to the parent
dataset it copies. However, when trying to induce it to write in
GDT_Float64 instead of int32, it brings out the fil
Hi Yann,
I had this same problem and found no other solution than to switch from
CreateCopy() to Create().
Good luck,
Sjur K :-)
Sjur Kolberg
SINTEF Energiforskning A/S
Sem Sælands vei 11
7465 Trondheim
tlf. 73 59 72 78
fax 73 59 72 50
> -Original Message-
> From: [EMAIL PROTECTED
Hello,
I would like to use GDALCreateCopy and change the datatype from int32
to float32.
GDALDatasetH hDatasetOut0;
hDatasetOut0 = GDALCreateCopy( hDriver1, ndviF,
hDataset1,FALSE,NULL,NULL,NULL);
GDALRasterBandH hBandOut0;
hBandOut0
Hello
On Fri, Nov 21, 2008 at 5:24 PM, Frank Warmerdam <[EMAIL PROTECTED]>wrote:
> You need to alter MSVC_VER to be 1400 in gdal/nmake.opt. Then the VB6
> still
> will be skipped. Currently building the VB6 stuff with visual studio
> express.
Thank you Frank, this worked fine (although it wor
Hi again,
the first problem was an input output argv[] confusion. I can load 350
files and it is OK. I may have another problem at the pixel level, but
in case i'll start a new thread.
Thank you Ivan for your suggestion, it would be meaningful indeed to do that.
void usage()
{
printf(
"
21 matches
Mail list logo
