[gdal-dev] Call for discussion on RFC 46: GDAL/OGR unification

[Etienne Tourigny]

With this RFC, you could achieve this using GDALOpenEx()

e.g. GDALOpenEx( "ASDFG", GDAL_OF_ALL, "QWERTY")


On Fri, May 16, 2014 at 11:01 AM, Ivan Lucena <lucena_ivan at hotmail.com>wrote:

> Even,
>
> Yes, it is hard to measure the impact of probing in a single file or any
> interactive command line operations.
>
> In the current API the class Driver doesn't expose the Open method:
>
> *Driver drv = gdal.GetDriverByName("QWERTY");*
> *Dataset dst = drv.Open("ASDFG");*
>
>
> IMHO that is a *missing functionality* in  GDAL API.
>
> GDAL API is a library to support Geospatial Data Abastration not just a
> format conversion tool. You should be able the use it even if your sole
> intention is do deal with the fictitious "QWERTY" format. IMHO. Yes, you
> can delete all the driver or put then all on the black list but that may
> not be the best solution.
>
> The frustration of some user/programmer could be that they know what
> driver they want to use and they don't want to waste time probing; they
> don't want GDAL to get confused by files that can be supported by driver A
> and B; and most important they want to process a very very large number of
> files (ETL) or repeated times (WEB).
>
> The RFC 36 is just a band-aid solution. It starts from the fact that some
> drivers already haven a prefix like "HDF4:" and use it to select the
> driver. As you can see, the suggested code is not that pretty [
> http://trac.osgeo.org/gdal/ticket/3043] since there is no Driver::Open
> method available.
>
> Regards,
>
> Ivan
>
> > Date: Fri, 16 May 2014 13:36:08 +0200
> > From: even.rouault at mines-paris.org
> > To: lucena_ivan at hotmail.com
> > CC: even.rouault at mines-paris.org; gdal-dev at lists.osgeo.org
> > Subject: RE: [gdal-dev] Call for discussion on RFC 46: GDAL/OGR
> unification
>
> >
> > Ivan,
> >
> > yes indeed, I missed that one. I'll update the RFC with it.
> > I think that the intent of RFC36 is covered by what is already proposed
> in RFC46
> > with the papszAllowedDrivers of GDALOpenEx().
> >
> > I do not think that specifying the candidate driver(s) is that usefull in
> > utilities since the time to launch them will be generally higher than the
> > probing time. But that could be easily implemented later with an option
> if that
> > was really needed (e.g. gdalinfo foo.tif -driver gtiff or possibly
> gdalinfo
> > foo.jp2 -driver jp2ecw,jp2openjpeg).
> > Due to the work I did in OGR drivers to avoid repeated file access by
> using
> > GDALOpenInfo*, I don't think that GDAL drivers should be affected. And
> the OGR
> > drivers are registered after the GDAL ones. So if the file being opened
> is
> > really a GDAL dataset, the OGR drivers should have 0 impact on the
> opening time.
> > I did try to benchmark a bit that, but it is difficult to come to a firm
> > conclusion since there are many factors: hot/cold runs, whether you
> spawn a new
> > process or use an existing one, etc.. And the time being measured are a
> few tens
> > of milliseconds, so very sensitive to task scheduling.
> >
> > Even
> >
> > > Even,
> > >
> > > I think that RFC 36 should be included in your list of
> > > related RFCs and should be reconsider for adoption since the
> unification
> > > would make the probing even more expensive.
> > >
> > > Regards,
> > >
> > > Ivan
> > >
> > > > From: even.rouault at mines-paris.org
> > > > To: gdal-dev at lists.osgeo.org
> > > > Date: Thu, 15 May 2014 20:47:32 +0200
> > > > Subject: Re: [gdal-dev] Call for discussion on RFC 46: GDAL/OGR
> unification
> > > >
> > > > Le jeudi 08 mai 2014 00:13:22, Even Rouault a écrit :
> > > > > Hi,
> > > > >
> > > > > This is a call for discussion on "RFC 46: GDAL/OGR unification"
> > > > >
> > > > > http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification
> > > > >
> > > >
> > > > No reaction : no interest or no time to review yet ?
> > > > Or should I move that forward ?
> > > > But I'd prefer if such architectural changes could be a bit
> reviewed...
> > > >
> > > > > Best regards,
> > > > >
> > > > > Even
> > > >
> > > > --
> > > > Geospatial professional services
> > > > http://even.rouault.free.fr/services.html
> > > > _______________________________________________
> > > > gdal-dev mailing list
> > > > gdal-dev at lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > >
> >
> >
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140516/28777a73/attachment-0001.html>