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

[Frank Warmerdam]

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

Ivan,

I'm not clear on what you are proposing above, possibly because you have
simplified the code a bit to much for me to follow your point.

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

I do *not* believe it is reasonable to expect drivers to register
"special prefixes".

I think the approach should be to examine the passed in
string, see if there appears to be a prefix like "HFA:", and
if so lookup to see if there is a corresponding driver.  If so,
try opening the file with that particular driver and with the
prefix stripped.

This logic will only activate if the prefix string matches a
driver name and there will be no conflict with things like
GTIFF_RAW.  By the way, I strongly dislike the suggestion
that these are "unlawful" names.

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

Note that using the complicated form is optional, and only needed
when there is a desire to pass open options.  Also, it would be:

  gdalinfo @driver=gtiff,landsat1.tif

The "@" prefix is the clue to kick into the special logic.  We would
likely want to avoid it if the file "@driver=gtiff,landsat1.tif" actually
existed in the filesystem.

The main advantage of the @ approach is that it is intended to be
easier to specify multiple open options.  Particularly on the OGR side
there has long been a desire to control how some DB opens are done
with extra open options but now the only way we can provide these is
via config options.   In any event, I am willing to back off this more
complex form so we can proceed with something promptly.

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

I'm afraid I still don't follow the above.

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    | Geospatial Software Developer