Re: [gdal-dev] Resquest for comments (RFC 36)
Ivan Lucena
ivan.lucena at pmldnet.com
Tue Oct 4 09:58:14 EDT 2011
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
More information about the gdal-dev
mailing list