[kde-edu]: Marble 0.5: The Road ahead

[Andrew Manson]

Yes just on the subject on what you forgot about the Gps, we'll need a
remodeled ui for the gps tracking thing too. Right now we have gps device
geoLocation and also i've just implemented ip. address geoLocation and as of
yet we don't have a way to choose between them.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-edu/attachments/20070820/a56a8402/attachment.html