[Gdal-dev] GDAL 1.4.0 RC1 Available

Ivan Lucena ILucena at clarku.edu
Wed Jan 3 09:24:00 EST 2007


Because Idrisi is a raw binary format it usually gets into trouble with
other formats drivers like Frank mentioned. We saw that happens before.

The reason for that is because raw binary does not have header the
initial pixels values can be interpreted as false match for driver that
checks for header information. 

I suggest placing GDALRegister_IDRISI first in the GDALAllRegister() and
I think that will be safe because this format is file-extension
dependent, and checks for it:

GDALDataset *IdrisiDataset::Open(GDALOpenInfo *poOpenInfo)
  if ((poOpenInfo->fp == NULL) || 
    (EQUAL(CPLGetExtension(poOpenInfo->pszFilename), ".RST") == FALSE))
    return NULL;

So, William, can you make that change in GDALAllRegister() and do some
test to check this theory?

That will be great. Thank you very much,


-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Frank
Sent: Wednesday, January 03, 2007 1:27 AM
To: William Kyngesburye
Cc: gdal-dev
Subject: Re: [Gdal-dev] GDAL 1.4.0 RC1 Available

William Kyngesburye wrote:
> On Jan 2, 2007, at 11:21 AM, Frank Warmerdam wrote:
>> Folks,
>> I have prepared a GDAL release candidate - 1.4.0 RC1.  I would
>> testing for critical errors that should be corrected before the
>> My hope is to promote RC1 to be the actual release this Friday.
>>   http://www.gdal.org/dl/gdal-1.4.0RC1.tar.gz
>>   http://www.gdal.org/dl/gdal140RC1.zip
> Still having a problem with my Idrisi/NetCDF bug:
> http://bugzilla.remotesensing.org/show_bug.cgi?id=1176


I have finally investigated, and it seems to be that the netcdf
library ncopen() isn't too safe in the face of arbitrary non-netcdf
files.  I intend to modify the netcdf driver to test files for a
netcdf magic code before passing to ncopen() to work around this.
However, the change is sufficiently involved that I don't want to
do it just now.

>> I have also published 1.4.0 autotest and doc files at:
>>   http://www.gdal.org/dl/gdal140doc.zip
>>   http://www.gdal.org/dl/gdalautotest-1.4.0.tar.gz
> Good.  I've been meaning to ask about an updated autotest.
> One test I've wondered about - DODS OGR, the test never worked and
> doesn't.  The error I get isn't very helpful as to why it's failing:

>   TEST: ogr_dods_1 ... ERROR 4: couldn't connect to host

> "Unable to open" doesn't really tell me if the NOAA server is not 
> responding or my DAP library is broken or the OGR DODS driver is 
> broken.  Previously I used DAP 3.6.2, updated to 3.7.3 now, same
> on both.

The "couldn't connect to host" is the real error message.  Apparently
server I was testing against has changed or moved or something and I
haven't had the inclination to adjust the script.  I likely ought to
my own DODS server for testing against, but this could easily be a bit
of work.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,

Gdal-dev mailing list
Gdal-dev at lists.maptools.org

More information about the Gdal-dev mailing list