[Qgis-developer] implementing a custom QGIS data provider

[Dave.DeHaan at sybase.com]

Good day,

SQL Anywhere 12---the soon-to-be-released next version of the DBMS from
Sybase iAnywhere---will offer spatial support modelled after the SQL/MM and
OGC standards.  I am interested in opinions as to the best way to interface
QGIS as a front-end GIS application backed by an SA12 database, ideally
approaching the capabilities and ease-of-use of the current PostGIS
interface.  In other words, I would like to achieve:
1. the DBMS's spatial capabilities (in particular, the spatial indexes) are
exploited; and
2. the installation/configuration of new clients using this setup is as
painless as possible.


>From my initial investigation of the QGIS documentation, I can see four
different possibilities (some of which may not actually work):

Option 1: Write an SA12 data provider plugin for QGIS in C++
  Pros: efficiency
  Cons/Questions: I'm not clear if or how C++ data providers can be
dynamically added to an existing QGIS installation.
    a. Is there a way to add new C++ plugins without recompiling the
source?
    b. If not, what is the QGIS policy on adding user-provided C++ plugins
to distributed binaries?

Option 2: Write an SA12 data provider plugin for QGIS in Python
  Pros: distribution/management is taken care of by the Python plugin
manager
  Cons/Questions:
    a. Is this even possible?  Looking through the repositories, I can't
find an example of a data provider written in python, or at least not one
that that allows definition of a DBMS-backed layer with full read/write
access.
    b. If it is possible, any idea on what the performance hit would be
compared to C++?

Option 3: Write an extension to the GDAL/OGR library for SA12, to be
accessed via "Add Vector Layer" -> Source Type = Database -> Type = SA12
  Pros: usability beyond QGIS to any OGR application
  Cons/Questions:
    a. if you currently try this and choose Type=Postgres, the new layer
has less capabilities than a native PostGIS layer (it disallows feature
deletion, along with certain other operations).  Is this a limitation of
the OGR interface, or is it a limitation of the OGR-PostgreSQL module?
    b. currently there are OGR modules available for Informix Datablade,
Oracle Spatial, ESRI GeoDatabase, etc.; however, a default QGIS
installation (v1.5) only lists the following Types: ODBC, ESRI, OGDI,
PostgreSQL, MySQL.  Assuming an OGR module was written for SA12, how would
one get it added to the drop-down list within the QGIS "Add Vector Layer"
dialogue?

Option 4: Use  "Add Vector Layer" -> Source Type = Database -> Type = ODBC
  Pros: no source code changes required
  Cons/Questions:
    a.  the generic OGR ODBC driver appears to be read-only.  This is
limiting and not acceptable in the long term, but possibly okay as a first
attempt.
    b.  I don't see how this could possibly exploit the spatial
capabilities of the DBMS, since the generated SQL queries will be
DBMS-agnostic.  If the spatial indexing can't be utilized then this option
is not sufficient.

Thanks for any suggestions or other advice you are willing to offer.

David DeHaan
SQL Anywhere R&D
Sybase Inc.