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

[Even Rouault]

Le mardi 04 octobre 2011 20:20:50, Frank Warmerdam a écrit :
> 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.

That's exactly my understanding of what the latest patch 
http://trac.osgeo.org/gdal/attachment/ticket/3043/open_by_drivername_v3.patch 
does.

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

Even if it is not in the scope of current RFC, do you have an idea of what the 
syntax would be for open options so as we can pick up something that could be 
later extended ?

Something like :

@[driver=drivername,]option1=value1,options2=value2,filename ?

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

Actually on OGR side, apart from the configuration options, you also have the 
notion of connection strings, like for the PG driver, to provide the driver 
name, database name, host, port, etc etc...

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