tackat at t-online.de
Sat Aug 29 17:13:13 CEST 2009
Am Samstag 29 August 2009 14:20:27 schrieb Anders Lund:
> I just joind marble-devel, with the intention to help improving some
> aspects of gps support in marble.
Great. I suggest that you first make yourself familiar with
> Specifically, I would like to help making marble suitable for loading,
> creating, displaying, manipulating, exporting and saving waypints, routes,
> and tracks (where applicable).
That's great. As you might have noticed there is a deprecated gps
implementation there already. But as I said it's old and outdated. So just
stay away from everything inside
marble/src/lib/gps <- Deprecated!!!!
marble/src/lib/AbstractLayer <- Deprecated!!!
All the real parsing stuff is located inside
marble/src/lib/geodata <- Use this instead!!
> I have been looking a bit at the source, and it looks like a good starting
> point would be improving gpx loading
Loading would be a good start indeed. However you need to make sure that you
implement it in a way that it's useful to Marble: We are currently working on
making Marble a GeoGraphicsView. See:
In Marble there are two sets of classes that you need to be aware of:
1.) The GeoData classes which represent a model that is designed after KML:
Please compare this with:
So these classes basically represent the "Model" and tool classes in which all
the properties get stored. Basically this means that all kinds of file formats
internally get stored in a KML-like data structure (this has got lots of
2.) GeoGraphicsItems: These classes represent the items in the view. They are
the geodesic look-a-likes of QGraphicsItems (with KML geometry classes in
Now how the implementation of GPS loading should work is this:
In KML every single object has got a Placemark (GeoDataPlacemark in our
classes) assigned. This Placemark has got a pointer to a Geometry object.
For GPS loading we'd do the same: Every single GPS object would get
represented as a Placemark!
So routes and tracks would _not_ be represented as new classes. They would
just be Placemarks that would have a (GeoData)LineString which has got a
(GeoData)Style that makes it look like a route or a track. All the very GPS
specific stuff would get stored in the ExtendedData object (which holds all
kinds of Metadata).
So I'd suggest that you look into all the GeoData stuff and KML parsing first
before you take a look at GPS loading.
Be aware that there are still lots of loose ends and that especially the
actual rendering and model classes still need quite some work.
> and saving
Saving would be cool, too -- once we have proper loading done ;-)
> (via the waypint, routepoint and trackpoint classes).
Nope. Eventually there won't be such classes. There will only be ExtendedData
for the Placemark which will give a cue as to what kind of object is
represented by the Placemark.
> Then, displaying and editing those data would be next.
The beauty of the whole "unified" concept is that the editing will work across
file formats. Andrew has worked a bit on this already (for "OSM" -- but as I
said it will work for all fileformats eventually as the view and model classes
are file format agnostic).
> Editing data could be done either in dialogs
> launched from the context menu, or in sidebars.
Yes, that would be nice. We have pretty high UI standards though -- but that's
> A sidebar listing the contents of loaded files would be nice, too.
Yes. Note that this listing would contain all the files loaded ( GPX, KML, OSM,
Shapefiles, etc.). There has already been work on this.
> I can see that data writing is more or less impelemnted, but there is no
> gui representation for that.
Andrew did some initial work on this.
> Now, I do not know if all this is within the scope of the marble
> library/widget, of if some of all of it should be provided as plugins?
Yes, it is inside the scope of the marble/widget. I'm a bit picky about the UI
(i.e. I want it to be simplistic, usable and not to get in the way of casual
users at all). But I guess we can discuss that at later point when we are at
the point where we need to change the UI.
> Also, I do not know marble code very well, so if I think wrong, or you have
> ideas or knowledge that I should know, that would be nice.
As I said: I'd suggest that you read the stuff on techbase. And that you
especially look into the KML data classes and parsing first.
On #marble / #kde-edu you can ask e.g. idis, real_ate, bholst, me, SaroEngels
and jmho if you've got further questions.
> In the hope that I can add a bit to marble,
We hope so, too ;-)
More information about the Marble-devel