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

Mon May 19 13:43:06 PDT 2014

hmmm may I suggest to use a short-handed version using a single character
string? While it is easy in python, it's a bit cumbersome in c/c++
(requiring 3 lines of code instead of 1)

something like
poDS = GDALOpenEx( "ASDFG", GDAL_OF_ALL, "driver", NULL, NULL);
poDS = GDALOpenEx( "ASDFG", GDAL_OF_ALL, "driver1,driver2", NULL, NULL);
or
poDS = GDALOpenEx( "ASDFG", GDAL_OF_ALL, "driver1 driver2", NULL, NULL);

cheers
Etienne

On Mon, May 19, 2014 at 5:28 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

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