[gdal-dev] OGR_Dr_Open deprecated

Ari Jolma ari.jolma at gmail.com
Fri Nov 13 13:13:45 PST 2015


I'm afraid I've missed this change quite much since it was so nicely 
backwards compatible.

It doesn't make sense to have two classes in the Perl bindings when 
there is really only one in the library - it's too confusing. That means 
I'll need to remove the OGR Driver and DataSource classes completely and 
leave only GDAL Driver and Dataset classes.

That's a backwards incompatible change and it should have been made in 
the 2.0 but it'll happen in 2.1 of the Perl bindings.

Ari


On 13.11.2015 16:37, Even Rouault wrote:
> Le vendredi 13 novembre 2015 15:17:40, Ari Jolma a écrit :
>> On 13.11.2015 15:58, Even Rouault wrote:
>>> Le vendredi 13 novembre 2015 14:48:02, Ari Jolma a écrit :
>>>> OGR_Dr_Open became deprecated in 2.0 but it is still the main method to
>>>> open vector datasets in the bindings.
>>>>
>>>> I just realized that I would need one method to open all data sets.
>>>> OpenEx seems to be it but I would still need to cast the object into a
>>>> Dataset or a DataSource.
>>> Just don't cast. You can use a Dataset for all purposes since the
>>> OGR_DS_XXXX API has been transposed to GDALDatasetXXXX and is already
>>> available in GDALDatasetShadow
>> Swig imposes typechecks that prevent that. It is like with the GDALGrid,
>> which takes a vector dataset.
> Not sure if it is a "swig" limitation, or something in the Perl bindings. But
> the Python and Java bindings for sure can use the vector part of
> GDALDatasetShadow.
>
>> I had to write an explicit cast function
>> for DataSource object into a Dataset object. Which I now realize is
>> probably not safe since there is an explicit warning against that in the
>> docs.
> At the C level, you can technically cast a GDALDatasetH to a OGRDatasourceH
> since the OGR_DS_ C functions end up calling methods of GDALDataset class. But
> you cannot cast a GDALDataset* to a OGRDatasource* since OGRDatasource* has a
> few virtual methods not available in GDALDataset*
>
>>>> Maybe OpenEx should be the preferred way to
>>>> open any data set also with the bindings.
>>>>
>>>> However, I don't seem to find good way to tell whether the data set
>>>> object OpenEx gives me is a raster or a vector. Is there such?
>>> If you open with OpenEx(filename, OF_VECTOR), so read-only + vector, then
>>> the few drivers that support vector and raster will return NULL if the
>>> dataset has no vector data and just raster. If you open with
>>> OpenEx(filename, OF_VECTOR | OF_UPDATE) and they support update mode,
>>> then they will return non-NULL even if the dataset has no vector data. A
>>> robust way of checking if there's vector data is to check
>>> GetLayerCount() != 0.
>> Thanks.
>>
>> I have so far ignored the OpenEx method. I'll develop it so in the Perl
>> bindings that it will return a raster dataset object or a vector data
>> set object depending whether the returned handle is raster or vector.
>> I'll also deprecate the old Open methods in the Perl bindings.
>>
>> Ari
>>
>>> Even



More information about the gdal-dev mailing list