[Marble-devel] Fwd: Re: [kde-edu]: Marble 0.5: The Road ahead

Andrew Turner ajturner at highearthorbit.com
Mon Aug 20 15:35:04 CEST 2007 

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
>


-- 
Andrew Turner
ajturner at highearthorbit.com      42.2774N x 83.7611W
http://highearthorbit.com              Ann Arbor, Michigan, USA
Introduction to Neogeography - http://oreilly.com/catalog/neogeography

More information about the Marble-devel mailing list