Marble/GeoData/GeoDataUse: Difference between revisions
m (moved Projects/Marble/GeoDataUse to Projects/Marble/GeoData/GeoDataUse: moving to GeoData related pages) |
|||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Using GeoData == | == 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 === | === Use Cases === | ||
Line 10: | Line 10: | ||
#: It is expected in that regard that classes have shared data. | #: It is expected in that regard that classes have shared data. | ||
#: Let's call this usecase the "ToolClass" usecase. | #: Let's call this usecase the "ToolClass" usecase. | ||
# use {{class|GeoDataDocument|kdeedu|4.x}} as the root document of a "data file" in-memory representation, or even another grouping of information. | # use {{class|GeoDataDocument|kdeedu|4.x}} 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. | #: In this use case, there would exist a "tree" of data matching a logical grouping of information. | ||
Line 16: | Line 15: | ||
=== Actual Implemented Use Details === | === 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. | * 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". Pure parameter passing benefits from shallow copy. | ||
* | * {{class|FileManager|kdeedu|4.x}} uses {{class|FileLoader|kdeedu|4.x}} which build a {{class|GeoDataDocument|kdeedu|4.x}} from files it opens. It internally uses the {{class|GeoParser|kdeedu|4.x}} classes and framework for xml files. Those files then provided through the {{class|GeoDataTreeModel|kdeedu|4.x}} model. | ||
* | * {{class|PositionTracker|kdeedu|4.x}} keeps a document with past positions retrieved from {{class|PositionProviderPlugin|kdeedu|4.x}} plugins. | ||
* | * {{class|RoutingManager|kdeedu|4.x}} handles routing data in a document with instructions retrieved from Marble Runners Plugins which derive from {{class|MarbleAbstractRunner|kdeedu|4.x}}. | ||
TODO others?? | TODO others?? | ||
Line 30: | Line 28: | ||
In the past or present, some issues have appeared and need to be remembered/adressed: | 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. | |||
Revision as of 21:51, 14 September 2011
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 Expression error: Unrecognized word "x". 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". Pure parameter passing benefits from shallow copy.
- Expression error: Unrecognized word "x". uses Expression error: Unrecognized word "x". which build a Expression error: Unrecognized word "x". from files it opens. It internally uses the Expression error: Unrecognized word "x". classes and framework for xml files. Those files then provided through the Expression error: Unrecognized word "x". model.
- Expression error: Unrecognized word "x". keeps a document with past positions retrieved from Expression error: Unrecognized word "x". plugins.
- Expression error: Unrecognized word "x". handles routing data in a document with instructions retrieved from Marble Runners Plugins which derive from Expression error: Unrecognized word "x"..
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.