[Qgis-developer] Best practice for a new Vector Data Provider

[Even Rouault]

Le jeudi 29 janvier 2015 11:55:40, Sverre Jonassen a écrit :
> Hi Jürgen,
> 
> Thank you very much for your reply. I will then go forward with approach nr
> 2).
> 
> > UTSL.  You can browse through all provider in QGIS and look for one that
> > is close to what you need.
> 
> Of course ;-) It's just that the source code doesn't really tell me what's
> best practice, it just gives me the options. Also I find it easier to
> understand architecture, requirements, and so on if I can compare the
> source code to "ordinary" documentation.
> 
> > Are you aware that you have to put QGIS providers and plugins under GPL? 
> > That means you have to make source code available to anyone you ship
> > binaries to.
> > That doesn't apply to GDAL/OGR drivers.
> 
> This point is definitely an interesting one. Together with Stefans point
> about using other OSGeo tools with the OGR/GDAL driver, we will have to
> seriously reconsider if the OGR/GDAL approach might be the best option for
> us after all.
> 
> 
> Best regards,
> 
> Sverre Jonassen
> +47 402 45 794
> 
> -----Opprinnelig melding-----
> Fra: qgis-developer-bounces at lists.osgeo.org
> [mailto:qgis-developer-bounces at lists.osgeo.org] På vegne av Jürgen E.
> Fischer Sendt: 28. januar 2015 21:28
> Til: qgis-developer at lists.osgeo.org
> Emne: Re: [Qgis-developer] Best practice for a new Vector Data Provider
> 
> Hi Sverre,
> 
> On Wed, 28. Jan 2015 at 12:05:25 +0000, Sverre Jonassen wrote:
> > I am currently trying to make a new vector data provider with a source
> > select dialog for QGIS so that QGIS can read and display data stored
> > in a custom format. The format in question proprietary to software
> > developed and maintained by the company I work at. I am quite new to
> > developing for QGIS and I am struggling to find the best approach to
> > do this. I hope that somebody out there can help me. I have not been
> > able to find any internet resources on best practices for a data provider
> > plugin.
> 
> UTSL.  You can browse through all provider in QGIS and look for one that is
> close to what you need.
> 
> > So far, I have succeeded in creating a very simple vector data
> > provider plugin and accessing it through a source select dialog (which
> > I have added to the src/ui/-folder). This is, of course, not a
> > suitable approach as it would mean that I have to build and deploy my
> > own version of QGIS instead of a plugin. As far as I have understood
> > it, there might be 3 possible approaches for me to make a new provider
> > with a source select dialog:
> > 
> > 1) An ordinary C++ plugin for the source select dialog containing the
> > 
> >    provider. Is this possible? I have tried this and so far not
> >    succeeded.
> 
> I don't think that will work.  QGIS divides plugins into "ordinary" plugins
> and providers.
> 
> > 2) A provider plugin containing all necessary ui. Is this possible? And
> > 
> >    if so, how can I add a menu-item to activate the source select dialog?
> 
> That's the approach most providers (meanwhile) take.  You can export an
> entry point "registerGui" that will be invoked with the application as
> argument. With that pointer to you can lookup UI elements in the
> applicat0on and create an insert new items you create.   Core providers
> usually don't use this and there UI is hardwired in the application - some
> using the "selectWidget" entry point.
> 
> > 3) A provider plugin without ui and a separate plugin with the source
> > 
> >    select dialog.
> 
> That used to be the normal approach, when providers weren't supposed to
> link the gui library.  As that changed I'd go for 2).
> 
> > A fourth option would be to create a plugin for OGR. This is, however,
> > not a good solution for me because I would run a high risk of data
> > conversion errors. Our format is much more similar to the QGIS
> > internal geodata model than to the OGR geodata model.
> 
> Are you aware that you have to put QGIS providers and plugins under GPL? 
> That means you have to make source code available to anyone you ship
> binaries to.
> 
> That doesn't apply to GDAL/OGR drivers.

True... but if used in a QGIS context, the obligations of the GPL license  
also normally apply to code linked with QGIS, so in the end the obligation to 
make source code available when shipping binaries would also apply. But we're 
not going to enter a debate on licensing issues...

> 
> 
> Jürgen

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com