Marble/GeoData/GeoDataUse

    From KDE TechBase
    Revision as of 17:35, 31 July 2009 by Tampakrap (talk | contribs) (Created page with '== 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 issu...')
    (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
    The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

    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:

    1. 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.
    1. use Expression error: Unrecognized word "x". as the root 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.
    • Reading a file with Expression error: Unrecognized word "x". creates a tree of data.

    This data is manipulated within a stack of Expression error: Unrecognized word "x".s and internally stored in QVector of value types like QVector<GeoDataFeature>

    • PlaceMarkManager creates its copy of any placemark in opened files
    • 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.

    Proposals

    TODO