|
|
| (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].
| |
