Marble/GeoData/PointerVsImplicitShare: Difference between revisions

From KDE TechBase
No edit summary
(Page moved to community wiki)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
{{ Moved To Community }}
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)
 
=== Others ===
* '''GeoDataHotSpot''' This doesn't use Geo coordinates. I'm not sure if this really is GeoData, at all (I have not checked for what it is used).
 
=== 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>)
 
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 [http://code.google.com/intl/de-DE/apis/kml/documentation/kmlreference.html#object here].

Latest revision as of 17:44, 25 October 2016

This page is now on the community wiki.