Marble and GeoClue - the dynamic duo?

Henri Bergius henri.bergius at iki.fi
Mon Aug 20 12:11:50 PDT 2007


Hi,

On 8/20/07, Inge Wallin wrote:
> Now, on first look, the match seems perfect: Marble is an application that is
> used to visualize maps and other geographical data. GeoClue is an
> infrastructure for providing exactly such applications with data.  What could
> be better.

This was the thought I also had when I saw a Marble demo in State of
the Map. It would be great if we were able to collaborate here.

Thanks for the comments and questions! I'll do my best to answer them below:

> 1. What is the status of the GeoClue project?  My impression is that it's in a
> pretty early phase.  Andrew writes that the DBUS protocol is stable, but that
> is not the impression that I get from the mailing list.  For instance, I saw
> a remark that somebody wanted to commit quickly so that his API isn't broken
> again before he gets the chance.

We have been doing some major API changes over the maemo/geoclue
summer of code project, and some API changes have been part of that.
These changes have included addition of the new civic (human-readable)
location API on side of the more machine-readable coordinates API, and
renaming D-BUS interfaces from foinse-project to freedesktop where the
project is now hosted.

GeoClue 0.8 is now done and works, and the idea is to freeze the API
to this stage so application authors can start using location context.

To get an idea of what GeoClue can do now, check out this screenshot:
http://www.flickr.com/photos/bergie/1183413084/

> Can we trust that if we implement support for GeoClue that we won't have to
> change it later?  Additions is not a problem, but we don't want millions of
> users to have their system break because the API / protocol wasn't correct
> the first time.  A way around this might be to introduce a protocol version.
> Future versions of Marble can then query the GeoClue server for the protocol
> version and adapt to it.

We want to provide a stable and working API, and so protocol
versioning is a strong option.

> 2. On the wiki, you mention a number of services that you want to support.
> Right now, the most interesting of them is Positioning.

Wiki is currently quite outdated, but should be fixed before we close
the SoC project.

Current services implemented are positioning (manual, hostip, plazes
and gpsd backends) and geocoding (yahoo backend).

> I see some problems with frontend - backend separation here...  Surely the
> backend is not supposed to propose Routing between positions?  Isn't that a
> natural feature of an application?

Theoretically we could have a routing service querying route data from
web services or generating it from local OSM data. But probably at
this stage (and maybe indefinitely) this is better left for
applications themselves.

> Also, what is the 'Map' service supposed
> to be? I couldn't find any real explanation for it on the wiki.

There was a stub map display widget in the original sources, but IMO
this is better done on toolkit/desktop level.

> 3. Regarding settings: This is a project hosted on the freedesktop.org server.
> You also mention that you want this to be a cross-desktop backend (something
> I agree with very much).  Yet, I see several mentions of storing settings in
> gconf, the Gnome configuration storage.  I must confess my ignorance here,
> since I don't know how other freedesktop.org projects handle this issue, but
> to me that sounds like a pretty *non*-cross desktop solution.

We currently use Gconf. This is definitely something that needs to be
discussed. I'm not very familiar with KDE's configuration system, so I
have no idea how difficult this would be to abstract.

One approach is to treat GeoClue's configuration storage as a "black
box" and simply deal with the services themselves.

> 4. Also regarding platforms: Marble, and I imagine other applications, are
> already portable to not only Linux, but other Unix-like systems and also
> Windows and Mac OS X. We cannot depend too closely on solutions that are too
> platform-specific.  What is the status of GeoClue in this regard, and what
> are the plans for the future?  Is there a roadmap?

We have focused so far on Linux, but I don't see problems with making
GeoClue run on any platform where Dbus is available. Non-dbus
implementations might not make much sense, though.

> 5. Downstream: What relations does the GeoClue project have with the Linux
> distributions and people on other platforms?  Is there or will there be
> binary packages of GeoClue?  If there will be, do you know when?

We haven't actively looked for packagers yet because of the stage of
the project. With GeoClue 0.8 it starts to be the time to look at
packaging it to various distributions.

The first UIs of GeoClue have been implemented for the maemo platform
and there we already have packages (which are moving to the official
"extras" repository later this week).

> Inge Wallin

/Henri

-- 
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius at gmail.com
Jaiku: http://bergie.jaiku.com/


More information about the GeoClue mailing list