[Marble-devel] Marble and GeoClue - the dynamic duo?
Inge Wallin
inge at lysator.liu.se
Mon Aug 20 19:31:16 CEST 2007
Hi People,
This mail goes to both the marble-devel and geoclue mailing lists. I believe
that these two groups are pretty separate and unaware of each other so let me
recapitulate some facts...
Marble is a desktop atlas application which will be part of the KDE education
module, but also exists in a stand-alone variation that is totally free of
any desktop affliction. I am one of the two maintainers of Marble. You can
find more information about Marble at http://edu.kde.org/marble, and also see
some videos of it.
We, the Marble team, released a new version of our software, and our head
maintainer then sent an email to our mailing list discussing the road ahead
for next version. One of the features we have already developed, but which
is not yet integrated is support for GPS units.
Andrew Turner of GeoClue sent a reply to this, making us (at least me) aware
of the existence of the project with some hints that Marble could perhaps use
GeoClue as a backend for providing some services, most notably the current
position. Here are my thoughts about this and I'll end with a number of
questions.
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.
However, I see some issues with GeoClue as it is today, which makes it
difficult to use immediately. Some of these issues might be my own
misunderstandings and some may be based on out-of-date information. I have
read all the emails on the GeoClue mailing list and also the Wiki. Perhaps
you can help me clear up any misunderstandings. Please also remember that I
am not a native English speaker, so if I sound confrontational that is not my
intention. So, on to the questions then.
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.
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.
2. On the wiki, you mention a number of services that you want to support.
Right now, the most interesting of them is Positioning. What is the status
of the various services regarding stability (design and implementation)?
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? Also, what is the 'Map' service supposed
to be? I couldn't find any real explanation for it on the wiki.
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. Also on the
mailing list, I see no mention whatsoever about contacting KDE people, but
several mentions of Gnome and Guadec. Now, I know that we/you have to start
somewhere, but if the intention is truly cross-platform compatibility this
issue must be dealt with.
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?
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?
Ok, that was a lot. Don't get me wrong here; I think GeoClue is a good idea,
and it would be a very natural backend for Marble if it was already
established and stable. I think it would be a good idea if you could release
something small with just the positioning service pretty soon and also
introduce some forward compatibility by using version numbers for the
protocol.
Best regards,
Inge Wallin
The Marble Team
On Monday 20 August 2007 15:35, Andrew Turner wrote:
> On 8/20/07, Torsten Rahn <torsten.rahn at credativ.de> wrote:
> > On Monday 20 August 2007 14:42:23 Andrew Turner wrote:
> > > On 8/20/07, Torsten Rahn <torsten.rahn at credativ.de> wrote:
> > > I believe you've all seen GeoClue:
> > > http://www.freedesktop.org/wiki/Software/GeoClue
> >
> > Well, we've seen it. Afaik the GeoClue project was born during the Boston
> > Desktop Summit which happened several months after we had suggested
> > exactly the same ideas (interestingly enough down to the same wording
> > being used ;-) at our aKademy meeting. Marble (earlier called
> > "Globepedia") was the result with the map widget being the part of the
> > framework we have put in most of the efforts so far.
>
> I wasn't at the Summit - and came on later because I believed in the
> goals of the project and its applicability to multiple devices,
> applications, OS's. So I can't speak for how the 'wording' was made.
>
> > From what I have seen there is pretty little code in GeoClue so far (at
> > least compared to the 30.000 lines of code that we have invested into
> > Marble so far).
>
> Ok, my email wasn't meant to be a "challenge" or in some way compete
> with Marble. I was merely pointing out that GeoClue exists and already
> handles the features that were being talked about being implemented
> for handling geolocation.
>
> As far as "pretty little code" - I don't think LOC really account for
> quality. The question should be - does it do the features we
> want/need?
>
> From my point of view, Marble has a different primary purpose:
> visualization of geography and geographic data. GeoClue is meant to be
> a system service for providing location. Building geolocation into
> Marble itself seems like a mixing of purposes - but that's just my
> opinion.
>
> > What I'd be fairly interested in would be agreeing on common (D-BUS)
> > interfaces and stuff that is not related to actual source code. That way
> > people could easily choose between Marble and GeoClue as a possible geo
> > services provider.
>
> GeoClue has a stable set of D-BUS interfaces from Backends to GeoClue
> Master, and from Master to Client applications (like Marble could be).
> I believe this is in the process of being documented by the Google SoC
> student - now that the implementation is finished and working for the
> current version.
>
> Marble Dev feedback would be welcome - and yes you are free to
> implement your own version of a 'master' or backends. A common D-BUS
> interface would keep things interoperable regardless of implementation
> options.
>
> I'd also like to say - development doesn't have to be a competition.
> We're all working towards the same goals, and often time/resources can
> be limted - especially with open-source/free development. Sharing
> implementation and using existing components as they are useful is
> beneficial to everyone.
>
> Besides, I'm a Mac desktop user, so I'm not beholden to KDE or GNOME
> 'camps'. :)
>
> > > The point being, instead of maintaining GPS, IP, and implementing
> > > numerous other geolocation methods - it may be worthwhile to see about
> > > using GeoClue - or at least weighing in about what you would like to
> > > see in it to make it useful to Marble.
> >
> > At the current early stage of both projects I don't think it's necessary
> > (at least not for 0.5 and 0.6 to decide on the backend). I don't exclude
> > that we might use GeoClue later on but until stuff has matured I think we
> > can live with friendly co-opetition.
> >
> > Torsten
> >
> > > Andrew
> > >
> > > > > thats it from me
> > > > > Andrew Manson
> > > > >
> > > > > On 20/08/07, Torsten Rahn <torsten.rahn at credativ.de> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Now that we (finally!) got Marble 0.4 out of the door, I'd like
> > > > > > to offer my
> > > > > > thoughts on what features should be part of the Marble 0.5
> > > > > > release:
> > > > > >
> > > > > > In my opinion Marble 0.5 should emphasize the work of the Google
> > > > > > Summer of Code students. All features need to get finished for
> > > > > > the public (So the features need to look finished and well
> > > > > > integrated into the user interface,
> > > > > > work as expected and should be easy to use).
> > > > > >
> > > > > > So to get into details:
> > > > > >
> > > > > > * GPS/GPX support: Not too much left as far as I can tell.
> > > > > >
> > > > > > - Make "File View" only appear if a document has been opened and
> > > > > > further fix
> > > > > > the UI.
> > > > > > - Do further tests for GPX file format compliance
> > > > > >
> > > > > > Andrew: Anything I forgot?
> > > > > >
> > > > > > * KML Support:
> > > > > >
> > > > > > From what I have seen the following essential features on Murad's
> > > > > > kml-tasks
> > > > > > list haven't been implemented yet (correct me if I'm wrong):
> > > > > >
> > > > > > 1. Show list view on the left that indicates opened kml/gpx
> > > > > > files. List view
> > > > > > should only appear if there are more than one opened file:
> > > > > >
> > > > > > This is partially done already:
> > > > > > - The "File View" has already been integrated by Andrew for GPX.
> > > > > > We need to
> > > > > > add KML support to it now as well.
> > > > > >
> > > > > > 2. Initial support of KML style objects (icon style, label style)
> > > > > >
> > > > > > The latter is rather unfortunate but I think we can live without
> > > > > > it for the
> > > > > > 0.5 release.
> > > > > >
> > > > > > There are two more show stoppers for 0.5 which are not on the
> > > > > > kml-tasks list:
> > > > > >
> > > > > > 3. Translation of KML files which is pretty much needed for KDE
> > > > > > 4. The idea to
> > > > > > solve this problem was to use Wikipedia's data as an online
> > > > > > download and get
> > > > > > their individual language data of the cities for translation. So
> > > > > > a user who
> > > > > > is from spain would have a database of cities downloaded in the
> > > > > > background which is compiled from the city data from
> > > > > > http://es.wikipedia.org/ and http://en.wikipedia.org/. That
> > > > > > means: http://en.wikipedia.org/ has the largest amount of cities
> > > > > > among all languages (about 160.000) The data base compiled for
> > > > > > spanish would contain those city names from en.wikipedia.org with
> > > > > > the ones that also exist in http://es.wikipedia.org/ replacing
> > > > > > the entries from http://en.wikipedia.org/ to make sure that they
> > > > > > get properly translated. This is just the rough idea.
> > > > > > I'll take care of compiling the data needed (with input from Tim
> > > > > > Alder from
> > > > > > Wikipedia).
> > > > > >
> > > > > > 4. Country support: For initial very basic country support it
> > > > > > would be nice if
> > > > > > we'd just add countries as "invisible" placemarks (i.e.
> > > > > > placemarks with no symbols). Problems:
> > > > > > - Where do we take the country data from (needs to have a Debian
> > > > > > compliant license)? This isn't too hard to solve though.
> > > > > > - The label for the country names needs to be specially aligned
> > > > > > and layouted
> > > > > > to make it look like a country name. So in opposite to real
> > > > > > placemarks there
> > > > > > will be only a single place tested (instead of 4), the label will
> > > > > > have a larger font, will be center justified and will probably be
> > > > > > displayed semi-transparent.
> > > > > > We need to adjust PlaceMarkPainter to either process the
> > > > > > countries as a different "layer" that gets rendered before the
> > > > > > city data (seperate KMLDocument). Or we need to change it to
> > > > > > display city data and country data
> > > > > > from a single KMLDocument (I'd rather prefer the further).
> > > > > >
> > > > > > Later on (for 0.6) this feature will get extended to make
> > > > > > countries to get "area support" (so the application is aware of
> > > > > > each area/shape covered by
> > > > > > each single country.
> > > > > >
> > > > > > Murad: is there anything I forgot?
> > > > > >
> > > > > > * Flat Map:
> > > > > >
> > > > > > There are three visible bugs in the implementation right now. I'm
> > > > > > pretty sure
> > > > > > all of them can be fixed within the next week. Except for that
> > > > > > further cleaning up and performance optimizations are needed.
> > > > > >
> > > > > > Furthermore there are two features that would be nice to have for
> > > > > > the 0.5 release:
> > > > > >
> > > > > > 1. Mercator projection (like Google Maps does)
> > > > > >
> > > > > > 2. Make texturemapper only update newly shown regions and reuse
> > > > > > the parts on
> > > > > > the screen that got rendered already before. This didn't work for
> > > > > > spherical
> > > > > > projection for obvious reasons so right now Marble still renders
> > > > > > and updates
> > > > > > the whole screen for each frame. However this trick would work
> > > > > > nicely for the
> > > > > > flat projection and would make moving around in Marble much
> > > > > > smoother and faster than for the flat projection (in fact as fast
> > > > > > as scrolling in khtml and kpdf).
> > > > > >
> > > > > > The latter would be something that we can live without (however
> > > > > > I'd really like to see it in 0.5).
> > > > > >
> > > > > > Carlos: Is there anything I forgot?
> > > > > >
> > > > > > Also we need to solve the remaining "Known issues" of the 0.4
> > > > > > release no latter than for 0.5 (Especially: fix the embarrassing
> > > > > > Wikipedia browser).
> > > > > >
> > > > > > None of the features we need for Marble 0.5 require further
> > > > > > translation string
> > > > > > changes as far as I can tell (and if there should be a few left
> > > > > > then please
> > > > > > add them before the string freeze on August 26).
> > > > > > We also need to make sure that work on all the features left
> > > > > > still gets started before August 26, so we are still in
> > > > > > accordance with the feature freeze. Except for the country
> > > > > > feature I think all of the other essential features have been
> > > > > > worked on to some degree. So that's the only issue left of
> > > > > > concern.
> > > > > >
> > > > > > Apart from beginning work on country support there is another
> > > > > > feature high on
> > > > > > the wish list: OpenStreetMap support: However I think we should
> > > > > > declare this
> > > > > > feature "optional" for Marble 0.5. It really should need only
> > > > > > little work on
> > > > > > Marble's source code to get this implemented (most work being to
> > > > > > setup the server with the right settings for the tile render
> > > > > > software). However 0.5is meant to focus on the work of the
> > > > > > students and I'd like to see 0.5released within the next 4 weeks.
> > > > > >
> > > > > > So that's my thoughts on Marble 0.5. Are there any things I've
> > > > > > been missing?
> > > > > >
> > > > > > --
> > > > > > Torsten Rahn
> > > > > >
> > > > > > Tel.: 0 21 61 - 46 43 - 192
> > > > > >
> > > > > > credativ GmbH, HRB Mönchengladbach 12080
> > > > > > Hohenzollernstr. 133, 41061 Mönchengladbach
> > > > > > Geschäftsführung: Dr. Michael Meskes, Jörg Folz
> > > > > > _______________________________________________
> > > > > > kde-edu mailing list
> > > > > > kde-edu at mail.kde.org
> > > > > > https://mail.kde.org/mailman/listinfo/kde-edu
> > > > >
> > > > > --
> > > > > Torsten Rahn
> > > > >
> > > > > Tel.: 0 21 61 - 46 43 - 192
> > > > >
> > > > > credativ GmbH, HRB Mönchengladbach 12080
> > > > > Hohenzollernstr. 133, 41061 Mönchengladbach
> > > > > Geschäftsführung: Dr. Michael Meskes, Jörg Folz
> > > >
> > > > _______________________________________________
> > > > Marble-devel mailing list
> > > > Marble-devel at kde.org
> > > > https://mail.kde.org/mailman/listinfo/marble-devel
> >
> > --
> > Torsten Rahn
> >
> > Tel.: 0 21 61 - 46 43 - 192
> >
> > credativ GmbH, HRB Mönchengladbach 12080
> > Hohenzollernstr. 133, 41061 Mönchengladbach
> > Geschäftsführung: Dr. Michael Meskes, Jörg Folz
> > _______________________________________________
> > Marble-devel mailing list
> > Marble-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/marble-devel
--
Inge Wallin | Thus spake the master programmer: |
| "After three days without programming, |
inge at lysator.liu.se | life becomes meaningless." |
| Geoffrey James: The Tao of Programming. |
More information about the Marble-devel
mailing list