File: project_design

package info (click to toggle)
marble 4%3A25.04.0-1
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 160,064 kB
  • sloc: cpp: 191,888; xml: 39,904; ansic: 7,204; python: 2,190; sh: 1,187; makefile: 235; perl: 218; ruby: 97; java: 66
file content (119 lines) | stat: -rw-r--r-- 5,068 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Project Guide:

As requested this is the guide on the way that i see the project
turning out. This is also for my own benefit so please excuse me if
I'm repeating things that you already know about.

----------------
Diversion - Abstract Layer
----------------

As a diversion to my main project goals i have been trying to
identify what is necessary to develop an Abstract Layer. This is
intended to be a framework from which a new Marble Layer can be
created easily. 

So far i have identified 2 main elements of a layer that would be
common to any instance of a layer, which are:
    1. Layer Data. This refers to an object that a layer is
       comprised of, for example a PlacemarkLayer will be comprised
       of Placemarks.
    2. Layer Container. This is to contain each Layer Item and to
       deal with any memory management necessary for dealing with a
lot
       of Layer Data objects. An idea for this memory management
       would be to have a binary file that represented all of the
       data and a QList for visible data, hence significantly
       reducing the memory footprint.

Each Data Object must contain any information necessary to draw itself
on a display.

Loading Available Data Objects can be done by a Thread to prevent
slow down of the system. A bitvector may be a good means to represent
which Data Objects are visible, leaving it so that the bit vector is
the only thing that is altered leaving the memory management to run in
the background.

Any Instance of either of these classes must inherit from them and
implement any pure abstract methods. For example a Placemark would
inherited from an AbstractLayerData.

--------------------
Main Project - GPS
--------------------

The main focus of this project is to modify Marble so that it can get
new data during runtime, this data being information on a GPS
Placemark. This will first require creating a GPS layer from the
previously mentioned Abstract layer classes.

A GPS Data Object would be an object that will provide GPS coordinates
from whatever means it can. There can be any number of GPS Data
Objects in the system and they will have to be contained within a
GPS Object Container object which will be in charge of:

    1.  Sorting out which data objects are visible (As available in
        the AbstractLayerContainer) and updating the special "I'm
        here GPS Data Object (specific to GPS Layer Container). This
        position will be added to a trackmark (and optionally a GPX
        file) whenever it is updated.
    2.  Keeping the GPS Data Object that is tagged as “me” to the
        center of the screen unless the user specifically
        requests that it does not happen. i.e. this is the default
        behavior.

Marble should also be able to show previously recorded GPX data, so a
method of adding new GPS objects from a GPX file to the GPS Layer 
Container.

Real Time GPS Data Objects (ones that can track moving objects) will
need to be updated with coordinates at a set interval of time. The
methods for obtaining these coordinates will be:

 1. Evaluating position from an ip address 

 2. Taking coordinates from a GPS device

 3. Finding the position of the Mobile Phone Cell that a connected GPRS
    or 3G device is “sitting on”   

 4. Allowing a user to input their current position manually.

I propose that there should be a distinction between all of the above
methods by identifying the GPS Placemark with a different icon for
each method of tracking. This will allow users that are viewing
broadcasted GPS Placemarks to know how their coordinates were
calculated.

Using the GPS Layer Container mentioned above it should be possible
to track a number of Real Time GPS Data Objects which may be connected
to the system from the internet via a live feed. This may be
implemented by creating a GPS Data Object in the local system
using coordinates from the live feed or alternatively it could be done
by displaying a single GPX file that would update in real time over
the live feed. The user should be able to keep any of these GPS
Data Objects in the center of the screen in the same way that it is
done for the GPS Data Object that is labeled “me”. For this reason it
would be necessary to make a distinction between all “other” GPS
Data Objects and the one labeled “me”, i propose this is done my using
separate colours.

All of the options necessary for handling GPS will be made available
in a side tab similar to Navigation and Map View. It will contain all
tools necessary to: 

 1. Select a method to track your own GPS Data Object, including
    none.

 2. Load any number of Real Time GPS Data Object from live feeds.

 3. Select a GPS Placemark to follow with the view. This should also
    be available by clicking a GPS Data Object in the view.

 4. Load a saved GPX file to the viewer.

The Starting point of this project will be to set up the Entire GPS
Layer and Load a GPX file into the viewer. Then the next step would
be to set up the methods for capturing live data for the current
user.