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:
{marble-data-base-url}/maps/earth/{theme}/{level}/{row}/{row}_{column}.jpg
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
