If you're a student and if you're still searching for a suitable GSoC 2008 idea then Marble might offer a chance to participate in a young, vivid and interesting project. We suggest that you have a look at the Google Summer of Code Ideas page. There are especially three ideas which seem to be exciting and very important:

• Vector Tiles: We'd like to see a similar concept implemented for all geographical features as the one we are using for Textures: Usage of tiles. Especially for vectors this would be interesting as we could live render e.g. Open Street Map or VMap 0 data.
• Panoramio/Wikipedia photo support: This would enable Marble to show thumbnails from georeferenced photos such as those from Panoramio, Wikipedia (or whatever image source is suggested by the applicant). Technically this work would extend Marble's KML support (which is currently being ported to a new QXmlStreamReader based framework).
• OSM Annotations: This project was suggested by Adriaan de Groot and Armijn Hemel and is meant to provide on-screen OSM Annotation support. Of course providing OpenStreetMap support is an important goal for Marble and the suggestions for this idea seem pretty reasonable and realistic for the given timeframe (and dealing with UMPC devices seems to promise lots of fun).

Of course we appreciate any other ideas for Marble development as well. Creative ideas get extra bonus points. If you want to find out what Marble Development is about then I recommend that you check out my "Marble's Secrets" blog entries:

• Part I was a Do-It-Yourself course about creating maps for Marble. We've seen how Marble manages to even display features such as aerial photos or OpenStreetMap.
• Part II showed how Marble paints the different map layers. We've also seen why Marble only needs very little disk space and memory for its default map - making it an ideal choice for solutions that involve little hardware resources (like the Asus EeePC and the OLPC).
• Part III looks beyond Marble's offline mode: It describes how Marble fetches its data from the internet.

But hurry up: Deadline for GSoC 2008 student applications is on Monday!

For help or questions you can join us on IRC ( irc.kde.org, #kde-edu ) or send a mail to our mailing list.

I hope that everybody who celebrated Easter has enjoyed some pleasant days (well and of course everybody else, too ... . Recently I've received a few e-mails from Thomas Hartmann who works in Trolltech's Qt/WinCE team. Thomas has started to port Marble to Windows CE after I had told him about Marble during the KDE 4 satellite launch event in Berlin.

After having seen a few screenshots of Marble running on Qtopia this is the fifth plattform apart from Marble on Windows, Mac OS X and Linux/Solaris/Unix. The high portability of Marble is due to the fact that Marble doesn't have any dependencies apart from Qt 4 itself (and it doesn't use OpenGL). So you don't even need to have KDE 4 installed to run Marble. However for users the KDE frontend is very much recommended as it has a few extra features that the Qt4-only frontend doesn't offer: like e.g. GetHotNewStuff support.

The fact that Qt offers the same API across plattforms (unlike other toolkits) has certainly helped a lot to make the Windows CE port possible. Of course Thomas had to strip down Marble due to the 32 MB memory limit, so the initial vector data isn't as detailed as for the desktop version (we hope that we'll find a GSoC 2008 student who will volunteer to implement vector tiles for Marble):

Thomas also created two youtube videos which show Marble on a Dell Axim X51v. The result is pretty impressive given that this PDA is using an XScale/ARM processor (which doesn't provide hardware support for floating point instructions):

This Wednesday Marble got fully translated to Czech (thanks to Vít
Pelčák) - including some fixes to the localized city names in the Czech Republic (thanks to Karel Volný). Recently I've looked closer at the KDE Localization Statistics which seem to have improved a lot during the last few months. What has become more and more apparent to me is the fact that Marble might soon be the virtual globe that has the best and most translated GUI on this marbleous planet. Ok, this shouldn't exactly be the primary concern of a tool like this (Yes, I hear you asking for more and better maps instead and we are working on that as well).




Caption: Marble's UI translated to Chinese (Credits for the Screenshot: John Smith).

But it's still interesting: Taking a peek into Google Earth's ~/google-earth/lang directory I can spot 14 files in the familiar .qm format. So I guess that Google Earth's user interface is available in 14 languages. With NASA's WorldWind it's a bit harder to say. But from what I was told there is no real translation framework available for the current stable version (However this is about to change with WWJ), so translations either need to get patched in or need a special plugin. As a result there are up to my knowledge no other languages officially supported apart from english (although the NASA WorldWind Wiki lists some translations).

Looking at our Localisation statistics I can see that Marble is close to 100% fully translated in Arabic, Catalan, Chinese (Simple & Traditional), Czech, Danish, Dutch, Estonian, French, German, Greek, Hebrew, Hindi, Italian, Japanese, Latvian, Low Saxon, Norwegian (Bokmål and Nynorsk), Polish, Portuguese, Punjabi, Romanian, Slovenian, Spanish, Swedish and Ukrainian. So according to The Count the stable version of Marble has GUI translation support for up to 26 27 languages ("Haha haha ha ...!"). With KDE 4.0.2 being near most notably absent are Krakhozian, Danish (thanks to Martin Schlander!), Farsi, Korean, Russian (thanks Nick! ), Turkish, and lots of other beautiful languages.




Caption: Marble's UI translated to Slovenian (Credits: Jure Repinc).

I understand that translation is a much more difficult task than most people might think -- especially for an application like Marble: There are lots of technical terms which don't get recognized as such easily -- even by translators:
For example the label of the "Relief" checkbox in Marble's legend reads "Relief" in English. This (or "shading") is the correct technical term in English and it's easy to understand for the mainstream audience. In German however the "official" cartographic technical term for this feature would be Schummerung. In my opinion this correct technical term is a pretty unknown word in German which has a strange sound to it and I'm pretty convinced that most people wouldn't immediately understand what it's about.

As the brilliant physicist and teacher Richard P. Feynman had pointed out on several occasions there is a big difference between knowing something and knowing the name of something. Of course it's a lot more important that people get a deep understanding of the nature of things than knowing the correct name. Still it's necessary to be easily understood and hence it is important to stick to wording standards. However these standards might vary depending on the audience you are talking to.

"Relief" is easily understood in German and gets the point across immediately (and it's not even an anglicism). Therefore I consider it a much better choice given Marble's target audience.

Now counting the supported languages of the GUI might be a nice thing to do for arithmomanians. But the real deal is translating the map:

Today we'll finish our first trilogy about Marble Desktop Globe:

• Part I was a Do-It-Yourself course about creating maps for Marble. We've seen how Marble manages to even display features such as aerial photos or OpenStreetMap.
• Part II showed how Marble paints the different map layers. We've also seen why Marble only needs very little disk space and memory for its default map - making it an ideal choice for solutions that involve little hardware resources (like the Asus EeePC and the OLPC).

In Part III we'll look beyond Marble's offline mode: We'll get to know how Marble fetches its data from the internet.




Caption: Left: Creating "KWorldClock 2" in 5 minutes using Marble's Qt Designer Widget Plugin. Note that this is just a proof that this would work today! - Actually Henry de Valence is working on a KWorldClock plasmoid already. Right: Marble showing off a real-time cloud map and Sun Shading with the "Earth At Night" map blended in.

By data we mostly refer to texture data. As of version 0.5.x (KDE 4.0) we only support a single texture layer. However this is about to change with the next version of Marble: David Roberts has added support for Sun Shading in Marble. If this wasn't exciting enough he also added a way to have the "Earth at Night" map blended onto the dark side of the earth. This includes a pretty nice Terminator line. On top of that he already added internal support for having real-time clouds as another layer! See the screenshot based on a current build of the Qt-version of Marble pre-0.6-SVN.

A really big mosaic of tiles ...

Actually I've met a lot of people recently who weren't aware of the fact that Marble downloads further texture data from the internet while browsing the map. On one hand the reason for this misconception is maybe the fact that we only provide very little additional online data right now (about 400 MB). On the other hand the map download is done automatically and very seamlessly in the background, so people will hardly notice. Andrew Manson created a nice YouTube video while he finished his GSoC Project "GPS support for Marble". During the first 1.5 minutes Andrew demonstrates what could be a summary of the "Marble Secrets Part II" hands-on paragraph: the video shows how you can hide and show layers using the legend tab. Watch closely at 1:35 where Andrew zooms into the "Earth at Night" Map: you can see how the map will suddenly show a lot more detail as new data has arrived on the computer in the background. Keep watching and you'll see the same happening with the "Satellite View" map.

From Part I we know that internally the current map gets provided at different sizes - each size at different resolutions. These different map "levels" are split into 675x675 pixel tiles each. Depending on the zoom level only those tiles that are actually visible will get loaded into the physical memory ("RAM") of our computer. This mechanism keeps physical memory consumption low. For each tile Marble will check first whether it's available in the physical memory's Tile Cache (yes, you were about to suggest this feature, but we got it implemented already!). If it's not available in the "Tile Cache" Marble will try to load it from the local hard disc. In case it's not there Marble will schedule the tile for download in Marble's very own HttpDownloadManager. But wait - what should we display in the meantime while there is no matching tile available? After all due to the way Marble works we can't simply "omit" the missing tile!

As a cheap but smart workaround Marble just scales up the tile at the biggest zoom level that is locally available for this particular place. It will then just cut out the area that is needed and will use this handcrafted DIY-tile as a temporary replacement until the "real" data arrives.

In the meantime the HttpDownloadManager will contact the server and will look for the tile in question (e.g. it might look for this one ) .
It's only convenient that on the server all the tiles get stored in the very same directory hierarchy as on the local hard disc:

So Marble will fetch the tile from the server and will store it locally on the hard disc - again sticking to the given tile directory hierarchy. Once it got stored locally Marble will update the temporary data of the texture tile to match the "real" data.

This mechanism works pretty well already. The HttpDownloadManager is also used to download the Wikipedia webpages that get displayed if you left-click on city labels or symbols.

If you're a real GIS person you might wonder whether it's possible to just replace this HttpDownloadManager with something "more sane" - like an enterprise database that has this data stored already. Yes, a suitable solution might be available in marble/src/lib/MarbleWidget.{cpp,h} where you'll find a method called: void MarbleWidget::setDownloadManager( HttpDownloadManager *downloadManager );
(soon to be changed to "AbstractTileProvider"). Just replace the HttpDownloadManager pointer with a pointer to your very own custom TileProvider class.

Get Hot New Maps ...

But what if you don't just want to zoom into maps that exist on your hard disc already. What if you want new maps on your computer?
DXS to rescue! DXS is the successor of "Get Hot New Stuff (GHNS)". It's a web service that allows applications to download and install data from the Internet in one single click.
So if you have the

In Part I we have seen how easy it is to create your own maps for Marble. We've also seen how this works down to the zoom level of aerial photos or OpenStreetMap. Part II will show how Marble manages to provide the biggest bang for the byte when it comes to providing map data. It outlines how we managed to get the default map squeezed into the 10MB package that the Marble-Qt version gets shipped with. We basically show ...

Why Marble is the perfect choice for Asus EeePC, OLPC & Co and some Embedded Devices ...




Caption: Marble running on my Asus EeePC and on the OLPC (OLPC photo kindly provided by Bernhard Rosenkränzer of ArkLinux fame)

If you followed our last part closely and did a bit hands-on work then you maybe have stumbled across the contents of ~/.marble/data/maps/earth/srtm . This one contains part of the data for the default topographic view which is pretty colorful to mimic the appearance of a typical school atlas. Although the Marble application focuses on the educational aspect that's only one reason why we default to the topographic map:

If you look at the actual tiles of the "Atlas" map then you will realize that they are all provided as grayscale bitmaps! If you actually replace "false" by "true" in line 10 of the srtm.dgml-textfile (which is likely placed in /usr/share/apps/marble/data/maps/earth/srtm/srtm.dgml if you're on a Linux/UNIX system) then your line should look like this:

Restart Marble and choose the "Atlas" map, zoom out a bit and you can see the grayscale data in "raw mode" in its full dull beauty. Actually you'll find out that it has a blue tint as Marble just applies the grayscale data to the blue color channel.

So apparently Marble takes the grayscale data, and somehow applies colors to it! This is pretty smart: All tiles get stored as JPG's. But grayscale images use up a lot less space on the hard disc drive than color images. Color images just need four bytes (RGBA) per pixel while grayscale only needs a single byte per pixel! And you can even compress grayscale tiles a lot more than color tiles: Usually people feel offended by highly compressed JPGs due to the violet-pinky artefact-shades that result from an overly compressed JPG-file.

With grayscale images this artefact is gone and it's much harder to tell a highly compressed image from an uncompressed one! That's the reason why Marble can store a lot more map data (about 4 times as much) in Atlas View than it would be possible in Satellite View!

The grayscale shades actually represent heights. In fact those grayscale shades are based on data that was acquired during the Shuttle Radar Topography Mission" ("SRTM") back in February of 2000: A radar system that flew onboard the Space Shuttle Endeavour during STS-99 mission obtained digital elevation models on a near-global scale from 56 °S to 60 °N. While Marble only ships part of the data the whole SRTM provides the most complete high-resolution digital topographic database of Earth to date! That's why the GIS community loves the SRTM data so much.

Now if we would just map those grayscale values to color values and if we would colorize our map that way then we would get a beautiful and clean map. We'd just choose a green-yellow-brown palette for all grayscale-values which represent heights above sea level. And we'd choose a blueish palette for everything below sea level - but wait: There are some large areas, e.g. in northern africa, which are actually below sealevel and which are not filled with water!
However several moons ago when Marble hatched from its spherical egg it worked exactly as suggested before. Back then it actually looked like this. Look at the upper coastline of africa and you'll spot some blue patches of water which are actually not supposed to be there ...




Caption: Left: Marble on MacOS X using beautiful high-res full-color SRTM tiles created with Mapnik (Credits: Artem Pavlenko). Right: Marble using the Altas map: notice the vector coastline blending with the texture data).

So we need some data for a coast line which enables us to choose the correct palette for the land and for the sea. Marble right now ships with such data which was very popular back in the 90ies: The "Micro World Database II" - which is based on some work by the Central Intelligence Agency, "CIA" back in

This is the first part of a new series about Marble. I'll try to address a few frequently asked questions as well as the current status of the development. So stay tuned.

If you've ever followed KDE 4 development then you've probably heard about Marble. Marble is a virtual globe which displays the earth. So Marble can be used as a nice digital replacement for your desktop globe at home where you can look up places.

But wait! There's more to it: Actually these days Marble can also display flat maps (thanks to Carlos Licea), can show different "map themes" and can serve as a Qt4-widget as well as an application! This means that as a programmer you can use Marble in your very own project as a map widget (License: LGPL). Marble was designed to run on any device and on any operating system supported by Qt4 without any further requirements. You can download the latest version of Marble together with KDE 4.0.1 here (It's part of the KDE-EDU module).

How Marble stores texture data

If you start Marble you might realize that the startup time is pretty good: It usually takes maybe 2-5 secs to start Marble (and we are working on improving that dramatically). If you zoom into the earth you might notice that Marble doesn't get slower while zooming in. Looking at the amount of memory being used up you will also see that memory numbers don't change either. No matter how much you zoom in it's as little as 65-100MB which is pretty lean compared to other virtual globes.
Among other concepts this is being accomplished by loading the map piece by piece. Marble uses a concept that is very popular among virtual globes: Quadtiles. In fact we are using the most simple form of Quadtiles compared to other more sophisticated solutions. We decided to do so for reasons of pragmatism and in order to keep things easy to understand for people who want to contribute to Marble.

This means that for different zoomlevels the map is available at different pixel resolutions:
level 0: 1350x675, level 1: 2700x1350, level 2: 5400x2700, ... . The highest zoom level currently provided from http://download.kde.org measures 86400x43200 pixel which equals about 500m per pixel at the equator.

Loading maps this large would exceed the physical memory or would at least take very long to load. So the maps are stored as a 2:1 ratio checkboard of several tiles. In Marble each of those tiles measures 675x675 pixel. The next higher zoom level gets created by dividing every tile into 4 pieces measuring 675x675 pixel each:

So level 0 consists of a row of two 675x675 pixel tiles (1350x675). Level 1 consists of two rows of 675x675 pixel tiles with four columns each (2700x1300) and so on. You can see this in the screenshots which also show the filenames of the tiles: They contain the row number (counted from north to south) and the column number (counted from west to east). As you can see Marble will only load about 5-6 tiles for any view. For Spherical Projection ("Globe") these tiles get mapped onto the globe.

So in theory there is technically no limit as to how far Marble can zoom into the earth. As you can see in the screenshot we have tested Marble with data from the kind folks from the OpenStreetMap Project ( http://www.openstreetmap.org ) already and there we are down to approximately level 13 where you can see objects that can reasonably get measured at the order of centimeters already (The test data tiles were kindly created by Artem Pavlenko of Mapnik fame).

During the very first application start of Marble you might have noticed that the first start takes a bit longer: According to the dialog Marble needs to "initialize the map". Actually it just creates the tiles from the huge base image while showing the dialog.

How to create your own maps in Marble?

Marble looks for maps on the local file system: these maps get specified in a .dgml-files. So that's what Marble will look for right from the start. Marble will search your home directory's ~/.marble/data/maps/earth as well as the respective system directory ( e.g. /usr/share/apps/marble/data/maps/earth ). The *.dgml file is a small XML-file that mostly contains

Today when I entered the office I found a welcome present in my mail folder that made my day: David Roberts had sent me a patch to put our Marble Earth directly into the spotlight of our G2V Main-Sequence Star (also known as "sun" among non-astronomers). That's totally awesome because this feature will allow kde-edu users to visualize things like seasons. This feature always has been on my personal TODO but I haven't been brave enough yet to start work on it myself because it deals with the (non-trivial) texture mapping code. So I'm thrilled to see that someone else has started to work on this!
Currently the code David Roberts has sent me works quite well already but still needs some fixes and larger speed optimizations. But that doesn't keep me from posting screenshots already:

On another topic Claudiu Covaci has used the Marble Widget to create a small application for a student project at the university. It shows the orbits of some theoretical (GPS) satellite orbits around the earth. He does it by creating a Google Earth KML file from the orbital elements and by feeding it to the Marble Widget. He has also sent me a patch that removed the last few issues with little additional code required. As a result I also post screenshots of the satellite-KML in Google Earth and Marble. As you can see Google Earth fails to display the possible satellite positions for the hemisphere that is targeted away from the observer:

I'd like to thank all the people that have sent me patches and bug reports (like the one I received from Toti today) for Marble recently.

In the meantime Inge and me are working on the next bug fix release Marble 0.5.1.

Hi everyone! Since yesterday our Marble Project has got a new mailing list for people who are interested in helping us to develop and promote Marble (and of course for people who use Marble to develop applications).
If you're interested in signing up on marble-devel@kde.org you are invited to do so here . If you want to join us on IRC, choose #kde-edu on freenode!

Great news for all people who like the Marble Desktop Globe: Google Summer of Code '07 has started and our vivid KDE community managed to get 40 students accepted - three of them will work on Marble! I've got to admit that I was pretty overwhelmed by the interest people showed in Marble: lots of students have submitted applications that dealt with Marble. Most of the submissions were great so it was pretty hard for sure to choose among them.

I hope that in the future we'll be able to get also those people involved whose ideas weren't accepted this time (especially the geocaching idea and the Marble Almanac). Right now I'm happy that now that Inge Wallin of KOffice fame has joined forces we'll have at least five people working on this tiny little project. For GSoC '07 topics will cover KML and GPS support as well as flat 2D projection.

In other news there have been lots of Marble packages for Linux -- thanks to Steffen "Whitey" Joeris, Beineri, Chitlesh Goorah and lots of others. However I'd like to point out that Christian Ehrlicher managed to create a Marble install package for Windows which is ready for download (keep in mind that Marble is still in early beta stage, so bugs certainly do exist). Now even if you are forced to use Windows there is no excuse anymore not to try Marble I hope people don't mind if I post a screenshot:

My last blog entry about Marble dates back a few months already, so I'd like to give a small update: Just recently I added a grid layer and a measure tool. For the curious here's how it looks like:

I also started to work on Wikipedia integration which isn't done yet, though.
If you're still searching for a Google Summer of Code 2007 idea, then maybe Marble is for you. I suggested several Marble ideas on our new technology portal KDE TechBase. But hurry up, the final deadline for GSoC 2007 application submissions is on Saturday already!
BTW: Quaternion SLERPs rock