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

Etienne Tourigny etourigny.dev at gmail.com
Tue Oct 4 11:35:16 EDT 2011


Hi all,

On Tue, Oct 4, 2011 at 9:58 AM, Ivan Lucena <ivan.lucena at pmldnet.com> wrote:
> 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.

IMHO this should be added by each driver in the GDAL_Register<driver>
functions, and the driver's name be added automatically to this list,
without any changes.

>
>>  >
>>  > 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?

As there are already a number of drivers which accept the
DRIVER:filename syntax, (therefore users and applications already use
that syntax) I would recommend using that syntax for the fast
detection also.

Perhaps both syntaxes could be valid, in order to accommodate OGR also?

1) <driver>:<filename> (e.g. gtiff:landsat1.tif)
2) driver=<driver>,<filename> (e.g. driver=gtiff:landsat1.tif)

I would add my 2cents and suggest that unusual filenames like
"hfa:example_file.img" and "@driver=ingres,dbname=test.tif" are rare,
and a fallback to the (slower) detection mecanism in these cases won't
be detrimental on average.

>
> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


More information about the gdal-dev mailing list