[Marble-devel] Re: KDE Geolocation Services

[Torsten Rahn]

Hi,

I agree that this will be likely one of the important topics at the Marble 
Sprint indeed.

Am Mittwoch, 3. November 2010 21:42:22 schrieb John Layt:
> part of the Meego platform.  The problem comes in the api to access
> Geoclue, which is a DBus based service with C bindings, as we would
> obviously prefer a Qt-ish C++ wrapper for convenience.

And for Marble we have a GeoClue plugin (I don't know whether it currently 
works since the DBUS API had been subject to changes at one point).
 
> Added to this is another issue I want to discuss with Marble: geo-related
> astronomical calculations.  With at least 4 different places in the SC with
> code for sunrise/sunset/moon phases (KHolidays, Plasma dataengine, KStars,
> Marble), and my needing them for the astronomical based calendars, it also
> seems a good candidate for a shared library somewhere.

That's something I'd like to see as well.

> Some of what I know about QtMobility:
> * Location api

I think that it probably makes sense to use the Location API for determining 
the position on platforms where Qt Mobility is widely deployed and where the 
implementation of the Location API is fully available. This would at least be 
the case for MeeGo and possibly for Windows (haven't tried).

> * Landmarks api

I think we have a big clash of design goals with regard to the Landmark API:

- One of the big ideas behind Marble is that internally it's modelled after 
the open OGC standard KML ( http://www.opengeospatial.org/standards/kml/ ): 
KML is popular, widely known and used in the world of GIS.
This has several advantages:

 * It's quite easy to learn Marble's API for anyone who knows KML

 * We basically have an implementation guide for all the classes and 
properties since everything is described as part of an open specification.

 * KML is a pretty pragmatic and at the same time powerful approach to 
modelling data. It goes way beyond just Placemarks (=Landmarks).

 * Due to the internal KML modelled design import of the open standard KML is 
quite easy to do. Also since KML is quite generic it's possible to map the 
parsing result of other formats (gpx, etc.) to KML.

- The idea behind the Qt Mobility API is to model a significant part of the 
API after Ovimaps' LMX format, see the "Landmarks Exchange Format 
Specification": 

http://www.forum.nokia.com/dp?uri=http%3A%2F%2Fsw.nokia.com%2Fid%2F9001c8de-
c19e-41a0-87d3-5be4297e4d4c%2FS60_Platform_Landmarks_Exchange_Specification_v1_0_en.pdf

From what I can tell it's barely known and barely supported outside the  
Ovimaps Symbian world. 
While the Landmarks Exchange Specification is more detailed with regard to 
some topics (and with regard to actual implementation) it lacks other parts 
(at least from what I can see) that are covered by KML. There are certainly 
some interesting aspects about the Landmark API (filters and categories) and 
parts where the Landmark API is more mature. 

The problem I see with using the Qt Mobility Landmark API is that we'd trade 
an internal design (and a public API) that is modelled after an open widely 
used specification and standard for a design that embraces Ovimaps internal 
design. In theory the advantage would be that this would allow for better 
usage of Ovimaps data (at expense of possible 1:1 KML import which I'd regard 
more important).

But there's a catch even with regard to the "better" Ovimaps import: 

> * Maps and Navigation api and widgets, including an Ovi backend

From looking at the current state of the Terms and Conditions of the Ovi Maps 
API I'm not sure whether we can legally make use of it:

http://qt.gitorious.org/qt-mobility/qt-
mobility/blobs/master/plugins/geoservices/nokia/OVI_SERVICES_TERMS_AND_CONDITIONS.txt

has some terms such as:

"4. USE OF OVI MAPS API DEVELOPER PACKAGE
[...]
You will not: 
(i) use or incorporate the Ovi Maps Service, Ovi Maps API Developer Package or 
any part thereof, in connection with any Application or other service (a) 
which has the primary functionality of providing turn-by-turn navigation 
services, real time navigation or route guidance; or (b) where such 
Application's functionality is substantially similar to the Ovi Maps or 
navigation/location-based products distributed by Nokia or its affiliates;"

Not sure whether this is supposed to stay like this in the shipped version of 
Qt Mobility and whether it affects Marble (which provides turn-by-turn 
navigation services, real-time navigation and route guidance e.g.).

Also in Marble we have the policy to only provide geoservices that are free in 
the sense of free software in the shipped version.  Shipping Ovimaps with the 
current Terms and Conditions would surely break that policy (which is one of 
our selling points).
 
Technically Marble already has full support in our stable versions for what 
you need to fetch Ovimaps pixmaps tiles (adding support is mostly about 
changing a server Url in an XML file AFAIK). 

> Against the Qt option, we obviously already have our own superb geo tools
> in Marble that we could work with to produce our own api, but somewhat
> smaller in scope than QtMobility or Marble itself:
> * basic geo classes like coordinates, location, address etc
> * Location api
> * Celestial Mechanics api

* Stuff like the GeoPainter which works well with projections
* Initial Qt Quick binding support
... and lots more.

Personally I think that it would be nice to have at least "conversion 
wrappers" available for Qt Mobility in some Marble classes (like e.g. for Qt 
Mobility's QGeoCoordinates vs. Marble's GeoDataCoordinates).

Best Regards,

Torsten