Projects/Marble/GeoData/PointerVsImplicitShare

< Projects‎ | Marble‎ | GeoData
Revision as of 16:09, 31 March 2010 by Bholst (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Implicit sharing and storing objects as value is very reasonable for basic data as QStrings, but there are reasonable doubts regarding Placemarks and other GeoData. There are some possibilities:

  • Don't use implicit sharing at all and store all objects on the heap with a pointer to it.
  • Use implicit sharing and storing as value for GeoDataCoordinates only.
  • Use implicit sharing and storing as value for all GeoData classes.

To find out which is the wisest I try to look at every single class: (please add your thoughts here)

Contents

Base data

  • GeoDataCoordinates This one is quite simple. It is not more than a QPoint in GeoCoordinates. This should stay implicilty shared.
  • GeoDataLatLonBox (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject
    • GeoDataLatLonAltBox same for this
  • GeoDataAccuracy Should be base data => value
  • GeoDataLod
  • GeoDataRegion I'm not sure if it belongs into this group ...


Geometric structures

  • GeoDataGeometry The base class for all geometric. We could want a pointer for this, so using it as data may not be the right way.
    • GeoDataPoint This one uses multiple inheritance (GeoDataCoordinates). I don't think that this is semantically correct.
    • GeoDataLineString
      • GeoDataLinearRing
    • GeoDataMultiGeometry
    • GeoDataPolygon

Features

  • GeoDataFeature These should be pointered, so GeoGraphicsItems could refer to them and change them easily.
    • GeoDataFeature
    • GeoDataContainer
      • GeoDataFolder (by the way, this is an object which probably wouldn't need a GeoGraphics representation)
      • GeoDataDocument (GeoDocument)

views

  • GeoDataAbstractView It's nothing more than a view, this could stay implicitly shared.
    • GeoDataLookAt Same for this as this is a child.


styles

  • GeoDataColorStyle
    • GeoDataIconStyle
    • GeoDataLabelStyle
    • GeoDataLineStyle
    • GeoDataPolyStyle
  • GeoDataStyleSelector
    • GeoDataStyle
    • GeoDataStyleMap (QMap<QString, QString>)
  • GeoDataHotSpot

It is possible to group these things in two groups:

  • objects that represent data which is actually shown on the map:
    • Features
  • objects that are abstract
    • everything else :)

I'm not sure to which of the groups the geometry classes belongs.

A compromise could be to use the classes of the first group with a pointer and all others as a value. In KML all items are children of GeoDataObject (except GeoDataCoordinates). See here.


This page was last modified on 31 March 2010, at 16:09. This page has been accessed 1,779 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal