Marble/GeoData/GeoDataUse: Difference between revisions

Revision as of 22:55, 12 August 2009

Using GeoData

this page tries to summarise the use of GeoData classes in marble so that its implementation details can match the use cases, and understand if any what issues might arise from manipulating them otherwise.

Use Cases

The use cases identified so far are:

use any GeoData class as a convenient data holder in APIs.
It is expected in that regard that classes have shared data.

Let's call this usecase the "ToolClass" usecase.
use GeoDataDocument as the root document of a "data file" in-memory representation, or even another grouping of information.
In this use case, there would exist a "tree" of data matching a logical grouping of information.

Let's call this usecase the "DataTree" usecase.

Actual Implemented Use Details

GeoData classes have shared data, in the sense that e.g. copying a GeoDataFeature is a shallow copy, with deep copy happening when one of the instances need to modify a value. This is all for the "ToolClass", and not much useful for the "DataTree".

Reading a file with GeoParser creates a tree of data.

This data is manipulated within a stack of GeoNodes and internally stored in QVector of value types like QVector<GeoDataFeature>. This is the canonical way to generate a "DataTree".

PlacemarkLoader as used by PlacemarkManager appends all placemark from files it opens in a PlacemarkContainer (which is a QVector of GeoDataPlacemark). This is another way to create a sort of "DataTree", relying on some "ToolClasses"

Model classes (implementing Qt's model-view framework that is) serve as interface to GeoData classes, passing them through QVariants

TODO others??

Common Issues and Pitfalls

In the past or present, some issues have appeared and need to be remembered/adressed:

memory ownership is an issue to be determined depending on use case.
Compliance with KML spec is a priority, limiting differing needs.
Parsing code is full of casts.
storing e.g. an GeoDataPlacemark item in a QVector<GeoDataFeature> looks like a hairy solution, as QVector<T>::append will internally create a new T. In the shared data context this implies that we end up with an element of vector being a GeoDataFeature with a private member being a GeoDataPlacemarkPrivate.
data which may be useful in the context of the "DataTree" use case are completely useless in the context of the "ToolClass" use case. This is true for featureId and other type defining attributes.
GeoDataFeature needs a copy constructor per derived class and each derived class has to be a friend of GeoDataFeature. This make the base class dependent on each derived class which is bad design.

Proposals

Using internally QVectors of pointers may limit the problem of inheritance. This does not limit the ability to use QVectors of Data types when needed elsewhere.

Providing some specialised "ToolClasses" like GeoDataCoordinates would limit the interference between the use cases.

@@ Line 34: / Line 34: @@
 # storing e.g. an GeoDataPlacemark item in a QVector<GeoDataFeature> looks like a hairy solution, as QVector<T>::append will internally create a new T. In the shared data context this implies that we end up with an element of vector being a GeoDataFeature with a private member being a GeoDataPlacemarkPrivate.
 # data which may be useful in the context of the "DataTree" use case are completely useless in the context of the "ToolClass" use case. This is true for featureId and other type defining attributes.
+# GeoDataFeature needs a copy constructor per derived class and each derived class has to be a friend of GeoDataFeature. This make the base class dependent on each derived class which is bad design.
 === Proposals ===