[Marble-devel] KDE Geolocation Services
tackat at t-online.de
Wed Nov 3 23:20:38 GMT 2010
I agree that this will be likely one of the important topics at the Marble
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
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
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:
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).
More information about the kde-core-devel