[Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)

[Etienne Tourigny]

Hi,

I followed your suggestion and created a QgsDataSource class, which
has been sub-classed in ogr and gdal providers (with just a tad more
definitions).

I could use another piece of advise...

The app opens a dialog when there are sublayers, so the user can
choose which layer(s) are to be opened.

Ideally this should be called without too much effort, and the
following approaches could be used:

- add a gui class to get selected layers, takes as argument the QgsDataSource
- run this automatically from QgsDataSource (or the provider
subclasses) - but this would require a dependency on qgis_gui which is
not cool for core/provider. Also may not be advisable for simple
queries.

any thoughts?


Also one more point...

Data sources inside zip/tar files are supported in qgis through the
VSIFILE mechanism from gdal/ogr.
A zip file can contain a mixture or vector/raster files so I was
thinking of creating a (small and simple) provider for handling these
files, since they should not be handled by both (gdal and ogr)
providers for detecting valid datasets.
Returned sublayers list couls be a mixture of vector/raster datasets,
easily opened through full uri.

Also vsifile allows for many other "virtual" files such as remote
files (http/ftp) using /vsicurl/url_to_file syntax
Qgis could be extended eventually to support these other VSIFILE
types, hence the argument to make it a provider.

More information on VSIFILE:
http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip
http://www.gdal.org/cpl__vsi_8h.html


Etienne

On Wed, Nov 21, 2012 at 10:41 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
>
> On Wed, Nov 21, 2012 at 12:14 PM, Etienne Tourigny <etourigny.dev at gmail.com>
> wrote:
>>
>> I agree that it would be good to implement this idea.  However it
>> requires a few changes in the API.
>>
>> Could this be done before 2.0, or after?  As it won't cause breakage
>> it probably would be ok to add afterwards. But I think that if it's
>> done after 2.0 not many plugins will use it.
>> However, this would probably be low in the priorities so it probably
>> won't make it.
>
>
> Both options are possible and I would be in favour of having it earlier than
> later... maybe it will become apparent that some breakage would be useful,
> so it would not need postponing until 3.0.
>
> Anyway regarding usage of new APIs in plugins, I wouldn't be afraid that
> plugin writers would not pick up new APIs. We have been introducing new APIs
> in 1.x releases quite often and people could decide whether they will prefer
> convenience of new APIs or compatibility with old versions.
>
>
>> I was perhaps thinking of a less complex way - a function which
>> returns a vector of QgsMapLayer given an uri, to replace
>> QgisApp::addMapLayers() but that is available outside of QgisApp.
>> Also the same for addVectorLayer() and addRasterLayer() (returning a
>> list of vector and raster layers, resp.)
>
>
> Isn't such function just a step away from a simple data source class?
> Because such function would be provider-specific anyway...
>
>
>> Then this code could be migrated to proper QgsVectorDataSource /
>> QgsRasterDataSource when possible.
>>
>> Which class could this go into?
>
>
> As a temporary solution you could just create a static method in
> QgsOgrProvider class and create a unit test in c++ (as it would not be
> available from python). But I would really like to encourage you to start
> with data sources :-) The interface in the beginning could be as simple as:
>
> class QgsDataSource
> {
> public:
>   static QgsDataSource* open( QString baseUri, QString provider );
>
>   QStringList layerNames() = 0;  // get list of sub-layers
>   QString uriForLayer( QString layerName ) = 0; // return full provider URI
> for a particular sub-layer
> };
>
> OGR provider would have its QgsDataSource implementation,
> QgsDataSource::open(path, "ogr") would simply create an instance of OGR's
> implmentation.

ah ok I thought you meant having a container for various layers - but
you mean a wrapper for the layer URIs that are inside a given data
source.

>
> Regards
> Martin