Hi, I have worked on implementing this, please give me any comments.
https://github.com/etiennesky/Quantum-GIS/tree/browser_scanitems 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. Etienne On Thu, Nov 22, 2012 at 2:11 PM, Etienne Tourigny <[email protected]> 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 <[email protected]> wrote: >> >> On Wed, Nov 21, 2012 at 12:14 PM, Etienne Tourigny <[email protected]> >> 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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
