Le lundi 19 mai 2014 22:43:06, Etienne Tourigny a écrit :
> 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);
In most cases, you will pass NULL as argument, so I don't think that will be
much an annoyance to have an array of strings. The issue with the single
string is that you never know which separator to use. A similar example is
with GDAL_SKIP and OGR_SKIP. In GDAL_SKIP, we used to have space as separator.
And in OGR_SKIP, comma.... (since there are OGR drivers with spaces in their
name "ESRI Shapefile"). In the branch, I've introduced a logic that tries to
detect the separator, while recommanding comma, but that's a bit messy. That's
why I'd prefer the array of string, even if it is a bit more verbose to
declare.
But if people feel strongly for the single string, that wouldn't be a big deal
to switch to that.
>
> cheers
> Etienne
>
>
> On Mon, May 19, 2014 at 5:28 PM, Even Rouault
>
> <even.roua...@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_i...@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.roua...@mines-paris.org
> > > > > To: lucena_i...@hotmail.com
> > > > > CC: even.roua...@mines-paris.org; gdal-dev@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.roua...@mines-paris.org
> > > > > > > To: gdal-dev@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@lists.osgeo.org
> > > > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > > >
> > > > _______________________________________________
> > > > gdal-dev mailing list
> > > > gdal-dev@lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
