QGIS » QGIS Application

• Summary
• Current status
• Work to be done
• Notes
• Changes
• Requirements for data model
• Use cases
  • High level diagram of 'old' data model'
  • The new data model is based on a 3-tier model

Summary¶

This document is intended as a space to discuss the re-architecture of the data model used by QGis as of version 0.8. The data model used up-to this release (and maybe later once) seemed to have grown in a 'natural' way which was govern by the needs to the individual developers. This resulted in class that duplicate functionality and which don't have a clear definition.

In order to provide a cleaner API for developer to handle data provider, datasets, etc., it seemed a good idea to take some time and re-architecture the data model for QGis. So, please chime in

Current status¶

This effort just started and produced only some initial ideas.

Work to be done¶

• develop requirements for the new data model
• create use cases (in progress)
• design the high level architecture for the new data model (in progress)
• detail design of data model components
• implement the data model

Notes¶

I'm not quite sure where the board is for what belong to the data model and what not. It's pretty clear that any GUI related component shouldn't be part of the data model. Yet, where do we put the layer components? I don't consider them as part of the data model, since it seems that layer are consumers of data and don't manipulate the data directly. Nevertheless, they are related to the data model since without them we wouldn't be able to visualize the data graphically. Therefore, I decided to include them in the use cases and the highlevel UML diagram. (PS: I would propose that a analysis similar to this one would be done for the presentation layer of QGis, in which layers and their components are analysed in more detail).

Changes¶

Dec. 13, 2006 (spoerri):

• added requirements
• added some initial use cases
• updated initial high level datamodel: I realized that the dataprovider shouldn't be based on data type (e.g. raster) but rather on the format(s) such as postgis, ogr, etc. Those providers would then return a dataset of type QgsVectorDataset, etc. This means, that a developer of a new data provider wouldn't only developer the dataprovider but also a subclass of type QgsVectorDataset, QgsRasterDataset, etc.

Requirements for data model¶

• flexible: it must be easy to add new data providers and datasets
• plugin based: as the previous model, the new model needs also be plugin based, such that new providers/datasets can easily be added
• modular: a developer should need to worry about the under laying data structure/format when working with a dataset, all the necessary functionality should be in the base class
• data format independent: the functionality of datasets should be independent/transparent from the underlaying data format. Note: the internals of datasets will obviously depend on the type of data provider (e.g. vector, raster, etc.), yet the API of the datasets should be the same across a given type such vectors, rasters, tins, etc.
• allow for data manipulation: the model needs to provide the possibility to manipulate datasets
• gui independent : the rendering of layers should not require QtGui classes and the gui for the specification of layer properties should be completely separated from the layer instance.
• qgs project independence : the map layers should be indepndent of the application so that they can be used in different vertical applications. For example code like this:

 mCoordinateTransform->destSRS().createFromSrsId(
       QgsProject::instance()->readNumEntry("SpatialRefSys","/ProjectSRSID",0));@

should rather be implemented using layer property acceessors and mutators (instead of using the global QgsProject instance)..

Use cases¶

Create Dataset:

1. Actor: user / developer
2. Description: The developer creates a new dataset to store data (spatial or tabular), the request is sent to the provider which creates an empty datasets and returns the dataset to the developer for further processing
3. Success: dataset can be created and reference is returned to developer
4. Failure: new dataset can not be created
5. Diagram:

Draw Dataset:

• Actor: user / developer
• Description: the user/developer wants to draw the layer, which request the necessary geometries for the current extent from the dataset which retrieves the data and returns the geometries (based on extent)
• Success: necessary geometries are returned and displayed
• Failure: geometries aren't returned
• Diagram:

Edit Dataset:

• Actor: user / developer
• Description: the developer initiates editing session (start transaction) during which one or more features are edited (add, delete, update). The dataset would then allocate a cache to temporarely store the edits. Edits would include geometry changes as well as changes to attributes. Once all edits are done, the edits session is terminated (stop transaction) and all edits are saved to the underlaying data source.
• Success: edits are saved successfully
• Failure: edits are not saved
• Diagram:

Select data subset:

• Actor: user / developer
• Description: the developer performs a selection against the dataset. The selection can be a spatial and/or attribute query. The dataset return a selection set. The selection set can then be used to display the selection in case (as in this use case).
• Success: selection set is returned
• Failure: selection can not be performed
• Diagram:

Comment: my knowledge for raster is a bit limited, so I'm not sure how well a selection set would apply to a raster dataset. Maybe in the form of a 2-D matrix reflecting the raster columns/rows???

High level diagram of 'old' data model'¶

The new data model is based on a 3-tier model¶

• presentation layer (main class: QgsMapLayer): used to display and symbolize the dataset on the map, print device, etc.
• business layer (main class: QgsDataSet): used to manipulate the individual dataset (e.g. shapefile, tiff, postgis table, etc.) and its features (e.g. add new attribute/field, update geometry, create pyramid, etc.)
• data layer (main class: QgsDataProvider): container for datasets, used to manipulate one or more entire datasets (e.g. delete dataset, list dataset, etc.)