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

Even Rouault even.rouault at mines-paris.org
Mon May 19 13:28:37 PDT 2014


Le vendredi 16 mai 2014 16:25:13, Etienne Tourigny a écrit :
> With this RFC, you could achieve this using GDALOpenEx()
> 
> e.g. GDALOpenEx( "ASDFG", GDAL_OF_ALL, "QWERTY")

Actually, this is an array of driver names: 

char** papszDrivers = CSLAddString(NULL, "QWERTY")
poDS = GDALOpenEx( "ASDFG", GDAL_OF_ALL, papszDrivers, NULL, NULL);
CSLDestroy(papszDrivers);

or in Python

gdal.OpenEx("ADSFG", allowed_drivers = ['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

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the gdal-dev mailing list