[Qgis-developer] Corrections of QgsOgrProvider implementaion of GDAL 2.0

[Mark Johnson]

>
> So if both a layerid and layername, you would prever layerid over
> layername ?

no, the other way around

Default: layername, only when a duplicate layername exists, should the id
be used
Checking for duplicate names is done in subLayers()
- if layername is unique, id will be set to -1 and sent to QgsOgrProvider

QgsOgrProvider would
- use GDALDatasetGetLayer if id >= 0
otherwise
- use GDALDatasetGetLayerByName

To solve the issue of several geometry fields we also need a (optional)
> parameter with the geometry column name.


subLayers() will send the layer name in the 'table_name(field_name)' format

It was only with gdal 1 that GDALDatasetGetLayerByName could not use that
format.
That means the 'table_name(field_name)' format can always be used.

>From a robustness point of view, I think we should be robust to layerid
> being absent from the
> URI (and I'd prefer that when we generate URI, we don't set layerId = -1
> but just remove it)
> since URIs can also been built by users and not only through the UI.

Since it is not a mandatory parameter inside QgsOgrProvider where the
string is being parsed, the default value of -1 will be used.
- so there is no need to store a -1 value in the project.

> We shoud also be robust
> to layername from being absent as well, as done currently.

Yes, also not a mandatory parameter
- at the moment QgisApp::askUserForOGRSublayers removes the layername sent
by, so everything also works without a layername  being sent.

I have started a manual merge into the QGIS 3 version, making sure that the
many changes are not disturbed.

Also all gdal 1 switches and the '>= GDAL_COMPUTE_VERSION(2,0,0)' will be
removed.

So I hope to offer a QGIS 3 pull request in the next few days.

---
I would also like to adapt QgsOgrProvider::ogrWkbGeometryTypeName
- to use QgsWkbTypes::displayString first
and only when not found to check for geometry types not supported by qgis
when needed.

ogrWkbGeometryTypeFromName must remain, since there is no corresponding
function in QgsWkbTypes.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170321/3332756d/attachment.html>