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

[Ivan Lucena]

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
> >
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140516/74e4b693/attachment.html>