Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
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...@gmail.com wrote:
On Wed, Nov 21, 2012 at 12:14 PM, Etienne Tourigny etourigny@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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
Hi 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. 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.) Then this code could be migrated to proper QgsVectorDataSource / QgsRasterDataSource when possible. Which class could this go into? Etienne On Tue, Nov 20, 2012 at 9:45 PM, Martin Dobias wonder...@gmail.com wrote: On Tue, Nov 20, 2012 at 6:16 PM, Etienne Tourigny etourigny@gmail.com wrote: Unfortunately the code that handles sublayer loading is in QgisApp, and I would like to add some tests for this in case it gets broken in the future. It broke a few months ago for rasters, and there ia a case where it doesn't work for vectors. Would you have a suggestion as to how we can improve this - i.e. manage sublayers outside of QgisApp? I think the sublayer handling should be done at the provider level. What is currently missing in QGIS is a notion of collection of layers. For example, OGR has data sources (usually a directory, server connection etc) which can be used for listing and accessing sublayers in a generic way - we need something like this also for QGIS provider implementations. Some providers already have some code going into this direction, but it's not exposed under a common API (e.g. QgsVectorDataSource class) - there is QgsPostgresConn or QgsSpatiaLiteConnection. The support for data sources would be also very handy for generic operations on layers (create, remove, rename). Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
On Wed, Nov 21, 2012 at 12:14 PM, Etienne Tourigny
etourigny@gmail.comwrote:
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.
Regards
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
Hi, I am trying to add some tests for the addRasterLayer() and addVectorLayer() members in QgisApp, and it seems I cannot have access to them from the test environment. I tried including qgisapp.h, but that needed an extra rule in CMakeLists (to add src/app to INCLUDE_DIRECTORIES), but this generated the following error when building In file included from /data/src/qgis/qgis-etiennesky/src/app/qgisapp.h:91:0, from /data/src/qgis/qgis-etiennesky/tests/src/core/testqgsvectorlayer.cpp:34: /data/src/qgis/qgis-etiennesky/src/app/qgssnappingdialog.h:22:38: fatal error: ui_qgssnappingdialogbase.h: No such file or directory compilation terminated. I also tried using QgsInterface from a python test, but it doesn't work because in tests/src/python/utilities.py QgisInterface is a stub implementation of the QGIS plugin interface How to get the real QgsAppInterface like when using a plugin? thanks Etienne ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
On Tue, Nov 20, 2012 at 5:52 PM, Etienne Tourigny etourigny@gmail.comwrote: Hi, I am trying to add some tests for the addRasterLayer() and addVectorLayer() members in QgisApp, and it seems I cannot have access to them from the test environment. [...] How to get the real QgsAppInterface like when using a plugin? Hi Etienne that's right, it's not possible to access QgisAppInterface outside of running QGIS instance. This has a reason: the interface provides various methods that make sense only when QGIS is running (e.g. access to map canvas, main window, toolbars). For testing purposes you could create a fake implmentation of QgisInterface, but that's most likely not what you want. IIRC addVectorLayer() and addRasterLayer() are just relatively simple wrappers around this code: layer = new Qgs[Vector / Raster]Layer( ... ); if (layer-isValid()) QgsMapLayerRegistry::instance()-addMapLayer(layer); I'm wondering what exactly are you trying to test... is it the core layer (and provider) loading or the connection with other QGIS components? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
Hi I understand that QgisAppInterface should only be available wen running the app. I am working with sublayer handling, which is not handled my QgsRasterLayer / QgsVectorLayer . Have a closer look at the various addRasterLayers and it's not as simple as you write (in part my fault - I hacked around existing code to add zip support and also raster sublayers). - vectors datasets can have multiple layers - rasters can have sublayers (subdatasets in GDAL) - zip files can have multiple layers/subdatasets Unfortunately the code that handles sublayer loading is in QgisApp, and I would like to add some tests for this in case it gets broken in the future. It broke a few months ago for rasters, and there ia a case where it doesn't work for vectors. Would you have a suggestion as to how we can improve this - i.e. manage sublayers outside of QgisApp? thanks Etienne On Tue, Nov 20, 2012 at 3:08 PM, Martin Dobias wonder...@gmail.com wrote: On Tue, Nov 20, 2012 at 5:52 PM, Etienne Tourigny etourigny@gmail.com wrote: Hi, I am trying to add some tests for the addRasterLayer() and addVectorLayer() members in QgisApp, and it seems I cannot have access to them from the test environment. [...] How to get the real QgsAppInterface like when using a plugin? Hi Etienne that's right, it's not possible to access QgisAppInterface outside of running QGIS instance. This has a reason: the interface provides various methods that make sense only when QGIS is running (e.g. access to map canvas, main window, toolbars). For testing purposes you could create a fake implmentation of QgisInterface, but that's most likely not what you want. IIRC addVectorLayer() and addRasterLayer() are just relatively simple wrappers around this code: layer = new Qgs[Vector / Raster]Layer( ... ); if (layer-isValid()) QgsMapLayerRegistry::instance()-addMapLayer(layer); I'm wondering what exactly are you trying to test... is it the core layer (and provider) loading or the connection with other QGIS components? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)
On Tue, Nov 20, 2012 at 6:16 PM, Etienne Tourigny etourigny@gmail.comwrote: Unfortunately the code that handles sublayer loading is in QgisApp, and I would like to add some tests for this in case it gets broken in the future. It broke a few months ago for rasters, and there ia a case where it doesn't work for vectors. Would you have a suggestion as to how we can improve this - i.e. manage sublayers outside of QgisApp? I think the sublayer handling should be done at the provider level. What is currently missing in QGIS is a notion of collection of layers. For example, OGR has data sources (usually a directory, server connection etc) which can be used for listing and accessing sublayers in a generic way - we need something like this also for QGIS provider implementations. Some providers already have some code going into this direction, but it's not exposed under a common API (e.g. QgsVectorDataSource class) - there is QgsPostgresConn or QgsSpatiaLiteConnection. The support for data sources would be also very handy for generic operations on layers (create, remove, rename). Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
