Re: [gdal-dev] Resquest for comments (RFC 36)

[Ivan Lucena]

Frank,

>  -------Original Message-------
>  From: Frank Warmerdam <warmerdam at pobox.com>
>  To: Daniel Morissette <dmorissette at mapgears.com>
>  Cc: gdal-dev at lists.osgeo.org
>  Subject: Re: [gdal-dev] Resquest for comments (RFC 36)
>  Sent: Oct 03 '11 21:04
>  
>  On Mon, Oct 3, 2011 at 6:14 PM, Daniel Morissette
>  <dmorissette at mapgears.com> wrote:
>  > I like the idea, especially since it can increase performance in some cases.
>  > However unless I'm mistaken the proposed patch seems to fall back on the
>  > regular test-open loop when the GDALOpenInternal() call with the explicit
>  > driver name failed, no matter why it failed. e.g. I specify the invalid
>  > "hfa:test.tif" open string, then I should get a NULL return value and not a
>  > handle to a TIFF file.
>  
>  Daniel,
>  
>  I believe that is because it is hard to know if HFA:test.tif was really
>  something other than a request for the HFA driver.  It could actually
>  be a file named "HFA:test.tif" or it could be that another driver happens
>  to use the HFA: prefix to mean something.   I believe this is an
>  effort to avoid failure in these cases.

I think that the concerns that Daniel and Jukka has expressed are legit.

As I explain to Jukka. It might not be a problem but it is still feels like a dirt trick. I mean, the "fall back" strategy.

So it would be better to do this instead:

{{{
    GDALOpenInfo oOpenInfo( pszFilename, eAccess ); 
    if ( oOpenInfo.bStatOK == false && strstr( pszFilename, ":" ) != NULL  ) 
    { 
        return GDALOpenInternal( oOpenInfo ); 
    } 
    return GDALOpenInternal(oOpenInfo, papszAllowedDrivers); 
}}}

And implement any kind of driver-specific string convention inside the function. 

>  > The patch would need to be reworked for this, but I think that if the
>  > GetDriverByName() call succeeds (i.e. the driver name prefix is recognized
>  > by GDAL) and the call to poDriver->pfnOpen() fails then we should return
>  > NULL to the application code (and not fall back on the test-open loop).
>  > OTOH, if the GetDriverByName() lookup failed, then we should fall back on
>  > the test-open loop.

But as Frank mentioned, we do have some drivers that use unlawful driver names, like GTIFF_RAW. For example, one driver that I wrote is officially called "georaster:" but it does accept "geor:" and people got used to that simplification. What we could do is to create a list of driver-nickname extracting information from a new driver metada entry.

>  >
>  > Also, if we implement this mechanism in GDAL, then we'd have to provide it
>  > in OGR as well to be consistent.
>  
>  I'm not convinced that this is necessary.  I have had a hope for
>  some time to provide a standard way of binding up open options,
>  including the driver name, for OGR as demonstrated by a
>  request like:
>  
>    @driver=ingres,dbname=test
>  
>  One objection I had previously to Ivan's proposal is that I'm
>  interested in pursuing this general purpose mechanism for
>  many open options in OGR and in GDAL.  But since I haven't
>  gotten to it for so long there is no point in holding up Ivan's
>  fairly straight forward change.  Nevertheless, I'm hesitant to
>  push his change to OGR unnecessarily.

I like that idea and I think it would address most of the concerns. 

It could like that, I guess:

$ gdalinfo driver=gtiff,landsat1.tif
$ gdalinfo driver=gtiff,gtiff_raw:landsat1.tif

It is not very user friendly (just because it requires more writing) but the intention is to be script-friendly and app-friendly anyway. Right?

That would require minimal change and it would be backward compatible:

{{{
    GDALOpenInfo oOpenInfo( pszFilename, eAccess ); 
    if ( oOpenInfo.bStatOK == false && EQUALN( pszFilename, "driver=", 7 ) ) 
    { 
        return GDALOpenInternal( oOpenInfo ); 
    } 
    return GDALOpenInternal(oOpenInfo, papszAllowedDrivers); 
}}}

We just need to load the driver informed and pass the string that comes after the comma as the pszFileName. No strips, not tricks, plain and simple.

I could write a patch and change the RFC if you want.

Regards,

Ivan