[Marble-devel] Hello

[Torsten Rahn]

Hey Anders,

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 

http://techbase.kde.org/Projects/Marble/GoMarble

> 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:

http://techbase.kde.org/Projects/Marble/GeoGraphicsViewOverview

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:

marble/src/lib/geodata/data

Please compare this with:

http://code.google.com/intl/de-DE/apis/kml/documentation/kmlreference.html

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 
advantages).

2.) GeoGraphicsItems: These classes represent the items in the view. They are 
the geodesic look-a-likes of QGraphicsItems (with KML geometry classes in 
mind).  

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 
another topic.

> 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,
> Anders

We hope so, too ;-)

Torsten