Hi,
I've been working with the OGR coordinate transformations for some time and
as long as I can remember, when calling the Transform function, no matter
what I'm transforming to or from I always need to convert the unit length
type of the Z component manually. For example, I've created a "from"
C
the projection
functions (ie OCTTransform) that are based on Proj.4. I have a project that
intends to perform a very large number of projections and any means to
improve performance in this area is critical. Any information that you could
provide would be greatly appreciated. Thanks.
Chr
Is there a way to quickly close a large dataset using the API? For instance,
I'm writing to very large TIFF file at which point the user cancels, the
code in turn stops what it's doing, closes the dataset, and deletes the
file. The problem is, since the file is around 5GB the close dataset
function
I'm just checking, but am I correct in my understanding that GDAL currently has
no support for 64-bit integer data types (long long). And if not is there any
plan to implement support. Just curious, thanks.
Christiaan___
gdal-dev mailing list
gdal-dev@l
I was wondering if I should file a bug report for this. I noticed that the
ENVIDataset class reads the RPC information from an ENVI .hdr file and places
the values in metadata objects prefixed with "RPC_" off of the default domain.
It was my understanding they shouldn't have the prefix and shoul
id? Thanks.
Christiaan
-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com]
Sent: Monday, June 01, 2009 11:24 AM
To: Christiaan Janssen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Erdas .img format (HFA) overview troubles
Christiaan Janssen wrote:
> After reading the HFA
After reading the HFA image format description, I was under the impression that
GDAL would support external .ovr files for this format but it seems that is not
the case. I ran quick test with gdaladdo ("gdaladdo -ro test.img 2 4 8") and
got the following error message: "ERROR 6: BuildOverviews()
I was recently trying to open a NITF (jpeg blocked) file whose size was roughly
5GB using the stable 1.6 release and having quite a bit of trouble. Namely, I'm
getting Access Violation Exception in the calls to CloseHandle. I dug around in
the source a bit and noticed the code for the NITFdatase
Does anyone know if it is possible to access any more of the NITF header data
than what is currently listed in the GDAL dataset metadata? There are a number
of fields that I have noticed missing, namely ICORDS & IGEOLO that I could
really use. I realize that these are image subheader components
, October 27, 2008 11:24 AM
To: Christiaan Janssen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] JPEG2000 question/issue
Christiaan Janssen wrote:
> I'm wondering if someone can help me with this. I'm trying to build
> GDAL with both support for MrSID and ECW while using the forme
I'm wondering if someone can help me with this. I'm trying to build GDAL with
both support for MrSID and ECW while using the former for JPEG2000 support. It
appears that as soon as libecw is linked in, it is being used as the JPEG2000
reader (even when I have MRSID_FLAGS = -DMRSID_J2K uncommente
:[EMAIL PROTECTED]
Sent: Friday, August 29, 2008 12:08 PM
To: Christiaan Janssen
Cc: Mateusz Loskot;gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Injecting Projection information in CreateCopy
I would take a look on how gdal_translate process the "-a_srs"
parameter:
http://trac.osge
2008 11:45 AM
To: Christiaan Janssen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Injecting Projection information in CreateCopy
Christiaan Janssen wrote:
> Could someone tell me the best/easiest way to create a copy of a
> GDALDataset from one format to another and specifying a projec
Could someone tell me the best/easiest way to create a copy of a GDALDataset
from one format to another and specifying a projection different than what is
contained in the source GDALDataset. I realize the CreateCopy does most of this
but I'm forced to use the projection contained in the source
I wonder if anyone else is experiencing problems with the
ComputeStatistics/GetHistogram functions. I'm running the latest build off the
cvs trunk with the ERMapper ECW SDK linked in. Whenever I try to call the
GetHistogram function (256 bins, 0-255 range) after running a ComputeStatistics
on a
Your help is invaluable, thanks again.
Christiaan
-Original Message-
From: Frank Warmerdam [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 4:54 PM
To: Christiaan Janssen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] CADRG subdataset access help
Christiaan Janssen wrote
would call GDALOpen as follows:
GDALOpen("NITF_IM:0:multi_1b.ntf", GDALAccess::GA_ReadOnly);
Christiaan
-Original Message-
From: Frank Warmerdam [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 3:52 PM
To: Christiaan Janssen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-d
How exactly does one go about accessing the raster data in an format that
contains subdatasets like CADRG? Any help would be greatly appreciated.
Christiaan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal
18 matches
Mail list logo
