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

Etienne Tourigny etourigny.dev at gmail.com
Fri Nov 23 12:08:44 PST 2012


I have worked on implementing this, please give me any comments.


There a few few things missing (like error messages) and a few rough
edges, but it works for opening vector, raster and zip datasets in
commandline, file open as well as file browser.
I have not tested for providers other than gdal and ogr.


On Thu, Nov 22, 2012 at 2:11 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> 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

More information about the Qgis-developer mailing list