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

[Etienne Tourigny]

>From my understanding of the RFC, legacy functions GDALOpen() would only
try to open the dataset using raster drivers and OGROpen() would only try
using vector drivers, so it shouldn't take more time than in gdal 1.x.

It also seems that this RFC addresses the need to specify the driver(s)
used to open the dataset. This effectively solves the problems raised in
RFC 36, as Even mentions. In my view no need to work on RFC 36 as this
should cover it (as long as the utilities are updated).

Looks good to me!

cheers,
Etienne



On Fri, May 16, 2014 at 8:36 AM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> 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/21295f0a/attachment.html>