QGIS » QGIS Application

Note: This document is currently under construction / incomplete

Introduction¶

This is a position document to describe a utopic QGIS. A utopic QGIS is one where the compromises to code style, code quality, user experience, code managebility, build efficiency and so on have bee minimised, making QGIS the best possible GIS environment for both users and developers alike. Obviously such a thing does not exist. However by declaring our vision of perfection we hope that it will focus minds towards a common goal and set of values.

Social Contract¶

If we are to make QGIS the best product it can be we all need to pull in the same direction. The ["Social Contract"] provides some pointers on how to maintain harmonius relations within the QGIS community. Sociology is an important part of our utopian vision for QGIS. We are all involved in QGIS because we are interested in it at some level. We should provide a social framework that encourages particpation, gives equal consideration to everyones ideas and fosters a balanced encouraging view on the world.

Useability¶

QGIS is a end user application. That is to say, our goal is to provide software for users who are computer literate, being familiar with the 'WIMP' (Windows Icons Menus Pointer) graphical user interface paradigm. These are our 'customers' and we should be aiming to provide them with the best experience possible.

The domain of QGIS is Geographical Information Systems. It is reasonable to expect that the users of our software have some familiarity with the domain. Either from past experience, or a desire to acquire knowledge of this domain. For this reason it is important to offer a user experience that is consistent with other products within this domain. We should and will take our cue from other GIS products so that users who have past experience within this domain feel some familiarity when encountering QGIS.

In general programmers tend not to be useability experts. We should make our software available to projects such as the Open Usability Project in order to attain the lofty goal of an easy to use yet powerful application.

The concept of useability should extend to the API and development framework too. The experience of programming QGIS should feel 'natural'. To do this we should strive for consistency and clarity, and shield the API user as much as possible from the underlying complexities of the system.

Useability should extend to the other resources associated with QGIS too. This includes the documentation explaining how to use and install QGIS, as well as the web site and other online resources.

Modularity¶

The logic encapsulated within the QGIS application framework has many environments in which it is useful. It would be a shame to build QGIS in a monolithic way such that the QGIS desktop application is the only product that emerges from all our hard work.

Libraries¶

Underlying the QGIS application framework is logic for reading and rendering a number of different GIS vector and raster formats, and for handling user interaction with spatial and attribute data. To escape this monolithic architecture we will be splitting QGIS into a number of libraries that aggregate functionality:

Code library components:

• libqgis - the core QGIS library
• libqgis_raster - a library of routines for manipulation of raster data
• libqgis_vector - a library of routines for manipulation of vector data
• libqgis_canvas - a library of routines for drawing maps onto a canvas
• libqgis_legend - a library for management of the map legend
• libqgis_composer - a library for composing maps in qgis
• libqgis_projections - a library providing facilities to project vector data

For more thoughts, see Martin Dobias's ["Splitting_Into_Libraries"] page, which also gives a good overview of potential demarcation boundaries. Each library should be able to compile and be used independently. This means for example, that if a developer is only interested in our raster rendering routines, they could compile an application that only links to libqgis_raster.

Designer Widgets¶

An additional factor we should take into account is providing a strong separation between parts of the code that provide GUI interaction, and parts of the code that provide the underlying algorithms for various parts of the QGIS feature set. In order to facilitate this we will create a series of designer widgets which will utilise the above mentioned libraries for their underlying logic but provide reuseable gui components suitable for use in QGIS and in creating third party applications. These widgets will include:

• QgsLegendView - A legend widget
• QgsMapCanvasView - A map canvas widget
• QgsMapComposerWidget - A map composition widget (will requiring refactoring to make it a non QMainWindow subclass)
• QgsPoinSymbolView, QgsLineSymbolView, QgsFillSymbolView - Widgets for describing symbology
• QgsMapOverview - An overview widget (which in turn uses a map canvas widget)

We should use the MVC design for implementing these widgets so that alternate views can easily be introduced by users of our API not happy with our GUI interfaces.

Plugins¶

Further modularity is provided via the plugin architecture which provides a mechanism for third parties to extend the QGIS core application while maintaining independent development paths. QGIS ships with a number of 'core' plugins (plugins included in the main source tree of QGIS). In addition various third party plugins exist both in the QGIS code repository, and 'out there in the wild', away from the QGIS project's management. An important aspect of our architecture roadmap should be catering for the long term stability of the plugin API, so that we provide no disruption to plugin developers as successive releases of QGIS are made. At the moment however this is impossible to guarantee as the plugin provides access to the entire QGIS runtime instance. This means that even small changes deep inside the QGIS internals could impact on plugin developers. To prevent this becoming an issue we need to formalise the plugin API. This is also needed for creating language bindings for e.g. Python. If we dont formalise the API, creating language bindings will be an onerous task. Formalising the plugin API will no doubt require considerable thought and discussion in order to balance API stability with API flexibility. Some useful resources relating to plugins are provided at: DevelopingPlugins and DebuggingPlugins.

Providers¶

A final aspect of modularity in QGIS is the provider architecture. Providers are data adaptors used to genercise the process of accessing data in various formats. The providers have a formalised API and are dynamically loaded at runtime - making it fairly easy for third parties to contribute providers for new data types as they emerge.

Consistency¶

API Consistency¶

We should make life as easy as possible for people wishing to use the QGIS API. In particular public interfaces for all classes should have predictable interfaces and should be consistent with the Qt library so that it feels like they are simply using an extension of Qt when programming in QGIS.

HIG¶

Similarly the user interface experience should be consistent. We need to develop Human Interface Guidelines (HIG) so that third parties developing plugins for QGIS can create software that is consistent with the QGIS experience. Similarly all dialogs withing QGIS core should provide a consistent experience. These guidelines should extend to things like:

• Placement of 'apply', 'cancel' etc buttons on dialogs.
• Style and colour scheme of icons and graphics
• Spacing between widgets
• The use of frames and other layout devices
• Capitalisation and use of text on dialogs

This is an area where non coders can make a useful contribution.

Documentation¶

An important aspect of any application is adequate documentation. We should provide developers with a well documented API. Where possible we should include examples of code snippets within the documentation that illustrates the use of various aspects of the API and makes it easy for new developers to get up to speed quickly. We should try to get our API documentation formatted as similarly as Qt's so that the once again developers feel like the QGIS API is an extension of the Qt library itself.

We should also strive to provide adequate documentation for general users, while at the same time trying to make QGIS as easy to use as possible so that no documentation is required.

Integration with other projects¶

There are many people creating great GIS and Remote Senseing tools, algorithms, libraries etc out there. QGIS should strive to provide a platform for these people and projects. To best meet their needs we should focus most strongly on map browsing and presentation aspects of QGIS, and then seek to integrate 'best of breed' tools from the open source GIS community. Currently on the roadmap the following projects have already caught our eye and have been integrated, or are planned for integration:

• GDAL/OGR - Used as the basis for much of the data access
• GRASS Integration
• ["Integration of QGIS and OSSIM"]

Use Cases¶

In addition to the above general architectural points, we have a collection of use cases that we think are important goals for Qgis to provide.

• To be able to open any gis related format vector or raster, in any projection and view, model and perform "analysis" (expand this?) and then save the resulting dataset in in any format
• To provide a better superset of libraries for third party developers than currently exist. Like a super gdal with libqigs_vector, or a great plotting engine with libqgis_raster+libqgis_canvas
• Fill in more use cases here. They should probably actually be much more fine grained eventually, but high end use cases drive the development. This CANNOT be a wishlist. It needs to actually be chosen. A laundry list of features will lead to a laundry list application, where each portion plays poorly with others, (kinda like the bad old days)