Today I have the pleasure to announce that Marble is the first popular virtual globe that ships and visualizes the Behaim Globe. The Behaim Globe is the oldest surviving terrestrial globe on earth. It was created between 1492 and 1493 - yes at the same time when Christopher Columbus made his first voyage towards the west and "discovered" America. This fact makes the Behaim Globe very special and also subject to scientific research: It documents European cartography during that era and it's probably the only historic globe which completely lacks the American continent.
These days the Behaim globe can be visited in the Germanisches Nationalmuseum in Nuremberg, Germany. The Germanisches Nationalmuseum (GNM) has kindly granted the Marble project permission to release the photo scan material of the Behaim Globe under the CC BY-SA 3.0 license and they have supported us in bringing it for the first time to the users of a widely deployed virtual globe: Marble. Right now our users can immediately download the Behaim Globe from inside Marble by entering File->Download Maps (or download it via our maps download website.).
Starting with the next Marble release scheduled for December 2015 the Behaim Globe map theme will become a regular part of the map themes that are shipped with the Marble installation package by default.
In addition the Marble project released a special Behaim Marble version in the Google Play Store. So users of Android devices – like smartphones and tablets – can enjoy the Behaim Globe, too! This also marks the first public release of a Marble based application on Android devices.
The Behaim map theme for Marble was created as part of the master thesis (Diplomarbeit) 3D Modelling of the Behaim Globe using Marble by Halimatou Poussami. The map theme allows to pan and zoom the whole Behaim Globe - curiously the whole globe is almost fully covered with detailed inscriptions in early modern German. Via checkboxes in the legend tab inside Marble our users can also overlay today's accurate coastlines. This allows to compare the Behaim cartography with today's known actual coastlines. Quite obviously the Behaim map depicts the continents stretched in longitude. So the creators of the Behaim Globe have probably based their globe on an earth radius value that was too small.
The photographic material of the Behaim Globe is based on digital scans made by the Friedrich Alexander University (FAU) in Erlangen-Nuremberg and the IPF TU Wien. These scans were performed using polarized light. This is also part of the reason for the vibrant colors that you can see in the map theme - visually the colors of the Behaim globe are much more subdued. During the past centuries the Behaim Globe has been subject to several "restoration attempts" and "editing", which also resulted e.g. in text changes. Therefore today's scientific research also focuses on the Behaim globe as a palimpsest. Using Marble's legend tab our users can compare the photomaterial of the Behaim Globe with facsimile drawings from 1853 and 1908 which also reveals differences.
The Marble Team would like to thank the Germanisches Nationalmuseum for its decision to release the Behaim imagery under the CC BY-SA 3.0 license. In particular we'd like to thank Dr. Thomas Eser (GNM), Prof. Dr. Günther Görz (FAU) and Halimatou Poussami for their active support in bringing the Behaim Globe to our Marble users and to the public!
Many pre-university students have participated in Google Code-In (2014) again and for many of them it has been the first opportunity to make contributions to Free Software and Open Source projects. In opposite to Google Summer of Code the GCI program is organized as a worldwide contest where students at the age of 13-17 years take the challenge to complete as many software development tasks from their mentor organizations as possible. These software development tasks are provided by Open Source Projects that are approved as mentor organizations. And at the end of 2014 KDE has participated as a mentor organization for the fifth year.
The most recent edition of Google Code-In, GCI 2014 has again been very successful: As Heena Mahour described in her Google Code-in 2014 wrap up with KDE there have been more than 277 tasks created by KDE mentors for the students which covered all aspects of the software development cycle and which ranged from creating source code to documentation, research, quality assurance and user interface tasks. It was amazing to see how the students solved nearly all of them and helped to improve KDE applications significantly.
As in previous years the top 24 performers became Grand Prize Winners and won a trip to Google Headquarters in Mountain View, California! In the KDE community the Marble Virtual Globe developers are usually actively involved with GSOC and GCI mentorship. Two of our students - Mikhail Ivchenko and Ilya Kowalewski - have made extraordinary contributions to Marble: They had worked very hard and contributed several important features to Marble - see e.g. Mikhail's blog post about the Tour (don't miss to watch the video!) and Ilya's blog about the Measure Tool improvements. And since they also earned most points they became Grand Prize Winners.
This year I was the happy one who went to Mountain View as a KDE mentor between June 7-10. And the trip was a great opportunity to learn more about the other mentors and the winning students (they were accompanied by a parent each) and to share more about our Free Software work in the KDE project. The Grand Prize Winner trip was lovingly organized by Stephanie Taylor and other members of the Google Open Source Programs Office: It began with a meet-and-greet event on Sunday evening in San Francisco to get to know everyone. On Monday we visited Googleplex in Mountain View. And on Tuesday we had a fun day in San Francisco where we had the choice to visit the Exploratorium, Alcatraz or went on a Segway tour through San Francisco. Being a science guy I picked the Exploratorium. On Wednesday it was time to say goodbye already after enjoying another round of Googler talks, delicious food and swags at the Google San Francisco Office. The whole experience was just awesome and I'd like to thank Stephanie, Carol, Cat and all the other Googlers for organizing this event and for giving us the opportunity to join it.
This year’s edition of Google Summer of Code ends tomorrow. We are required to cease coding, polish rough edges, fill in survey questions and write blog posts like this one. It has been an amazing summer during which I’ve learnt so much. I have evolved from a web newbie to a web enthusiast and had the chance to meet great people. Speaking of awesome people, I want to thank to my mentor, Dennis Nienhüser, for the always-friendly guidance he provided :) I also thank to my partner and friend Utku Aydın, with whom I collaborated very well.
Time for a last status report, now. During the final weeks, I’ve worked on the Marble Touch code to enable route and bookmarks synchronization on Marble-enabled devices. Route sync is finished and already merged into master. A glimpse of it can be seen in a screenshot:
Sync settings such as credentials and per-category toggling have been added as a Preferences entry:
Bookmark sync for Marble Touch is almost complete, but will be merged into master after GSoC. The desktop version of Marble has been completed by Utku, though, and is fully usable.
Thanks for a great summer, Dennis, Utku, KDE and Google!
1. Single Page App vs. Multi Page App
This was a hard decision to make. SPAs are more dynamic, but more difficult to design and implement. MPAs are easier to write, using simple templating available in ownCloud, but require page reloading, thus providing a less desirable interaction. I ultimately went for SPA for both the challenge and improved user experience.
2. Leaflet for rendering maps
Leaflet.js is a pretty JS library that I used to display routes and bookmarks over an OpenStreetMap layer. The library is easy to use and extend; I highly recommend it for displaying any geographical data.
3. jqTree for a nice tree of items
I have used this jQuery plugin for displaying a tree of bookmarks. It receives data as JSON and outputs it as JSON, allowing node deletions, drag and drop and more.
4. jQuery for DOM manipulation and Pure CSS for visual consistency
DOM and AJAX business was done with jQuery and styling was based on Pure CSS for nice menus in all browsers.
Since an <img> is worth lots of <p>s, I give you some screenshots:
The main menu shown after loading the app.
The Bookmarks tree.
A selected bookmark.
A bookmark in rename mode.
The routes menu with a route selected.
Creating the web interface was an interesting and educational activity. It was my introduction to «real web programming».
Next in line is the user interface for Marble Touch (mobile devices).
Things are going pretty well since my first progress report: route synchronization feature is almost complete! Marble users can store their routes on ownCloud easily now. All they have to do is to click to “upload to cloud” button when viewing a route. But first they need to tell Marble which server it will use for synchronization purposes. Users can use Marble’s own configuration dialog to do that:
By the way, adding KWallet support is on my to-do list.
Users can use “cloud routes” dialog to manage their cloud routes.
The first route is a route which is on the cloud and ready to use offline. The second route is already saved to user’s device, but isn’t on the cloud. For example routes which are created when offline will be in that situation. Users can upload those kind of routes manually by clicking to “upload to cloud” button. After I implement bookmark synchronization, I will also enhance route synchronization so Marble will upload those routes when there is a network available. The third route is on the cloud but not saved to the device. Users can download those routes to their device by simply clicking to “load” button. Also, when I enhance route synchronization those routes will be downloaded automatically by Marble. Don’t worry though, I will add an option to settings dialog so users can disable those automatic actions to preserve their precious data plans.
You can test the things I mentioned above yourself (and see how awesome they are :P) by cloning Marble’s master git branch. You can get the 3rd party ownCloud application that you need to install from Andrei Duma’s GitHub repository. We plan to setup a demo server with the Marble ownCloud application later as well.
That’s all for this update. Stay tuned.
As the title of the post already suggests, I’m glad to let you know that the patch adding support for the rendering of ground overlays has been merged to the Marble’s master branch.
After solving bugs that occurred mainly during the rendering of overlays having a GeoDataLatLonBox with a rotation parameter other than 0, Marble is now capable of displaying ground overlays by simply opening a KML file referencing one.
However, the rotation angle was not the only problem source, as issues also appeared when displaying overlays that extended over the antimeridian. In fact, this turned out to be the most annoying corner case, as dealing with it meant treating multiple situations separately and led to ugly code.
Unit testing has been another important part of the patch, as it was dependent on the GeoDataLatLonBox and TileId classes, to which we added new utility methods that had to be properly tested. One particular method returns the smallest bounding box of a rotated LatLonBox and is particularly useful for filtering out tiles that do not intersect with any ground overlays, improving the rendering performance significantly.
But I guess you might be more interested in what Marble can actually do now, so here are the screenshots you probably expected to see from the beginning (clicking on any of them will take you to an album containing more samples):
The work on the editor mode for overlays has started already, so you will soon be to edit the images in an interactive manner.
Hope you enjoy this new feature as much as I do. Stay tuned!
Yes, you guessed right. REST as in “Representational state transfer”, not as in “rest on the beach” :)
During the first two Summer of Code weeks, I’ve been working on designing and implementing a RESTful API for the ownCloud Marble app. This API will be used by my colleague, Utku Aydın, who is working on the C++ side of the project (Marble library).
What I’ve learnt until now:
The Routes API is completed and you can see my work on github.
Hello everybody and I’m happy to tell you about the progress of the project.
Unlike to what we had initially planned, we decided to start working on the rendering of the ground overlays, since it would eventually interact with the OpenGL project developed by René Küttner and Bernhard Beschow.
Since, I didn’t actually know much about how rendering was being done in Marble at that point, I had to do a lot of reading on figuring out how all the classes were connected, which types of projections were being used and with which we had to deal with, so it actually took more than I had initially expected.
If you don’t currently know much about overlays, they are basically pictures that get displayed on top of certain areas on the globe instead of plain terrain being rendered. They are an important feature of KML and they generally help the user to more easily explore the globe.
However, rendering multiple overlays is a time-consuming process and displaying them on the map may be done in multiple ways, depending on whether performance is preferred over display quality or viceversa.
If you don’t know much about how Marble renders data, you can read these articles on Marble’s implementation secrets: part I, part II and part III. They were written by Torsten Rahn in 2008 and, even though they are a bit outdated, you will be able to get a good idea of what Marble does behind the scene (part I is particularly useful!).
So, assuming that by now you have already taken a look over the articles I mentioned, we can move on to discuss the available options we have for performing the rendering.
Considering the fact that the tiles displayed on the map as a single paint event are actually the result of blending the tiles from different layers of a map (e.g. Satellite layer, Cloud layer, Street Map layer), the rendering of ground overlays could be approached by either of the following:
In terms of performance, these options would theoretically have advantages and flows, which could be described as follows:
As we couldn’t decide on implementing one of these beforehand, we decided to test an early implementation for each of them. As it turned out, the difference in quality isn’t actually as big as expected in the favour of the dynamic approach, so we might reconsider our options of rendering the overlays on the fly.
The only aspect that I can actually illustrate in this post is the quality of the rendered images. The performance difference was not significant for the small number of overlays used for testing, but it will for sure make an impact when using a large number.
The tile rendering approach is still a big buggy, but some conclusion can still be drawn at this stage.
So, to be more specific, here are some sample screenshots for an 128×128 JPG image for each of the cases. The first one was obtained using the tile rendering approach, while the second was was obtained by mapping the overlay during the texture mapping process (I used different rotation angles on purpose).
As you can see, the quality doesn’t differ and one could even argue that it fares better even in terms of sharpness using the tile rendering approach. You can have a look at more overlays being rendered at different angles and zoom levels using the respective approach by clicking on each of the pictures.
When using a higher resolution JPG image (400×400), the results looked as follows:
You can, as well as before, click on the images to get further examples of the rendering quality.
At this point, the performance becomes an issue and there the reduction of the rendering speed can easily be observed when trying to rotate the globe around. And we have to consider that this is only one overlay that we’ve been rendering!
At this point I think I can state my opinion that the tile rendering approach would be faster in terms of performance, cleaner in terms of code and almost as good as the dynamic rendering in terms of quality.
I would also prefer this approach since the dynamic one would also almost surely result in intrusive code (mapping the textures on a spherical surfaces doesn’t really have anything to do with the content of the rendered images).
That’s all for now. I hope we will be making a decision tomorrow and have the final version implemented as soon as possible! I am waiting for your opinions in the comment section.
Have a nice evening and see you soon!
My Google Summer of Code project, “Codename: Marblecloud”, will help Marble users synchronize their routes and bookmarks between their devices using ownCloud. Sounds cool, right? It will also pave the ground to synchronize all user data in the future when it is complete. To accomplish this breathtaking mission, a 3rd party ownCloud application which provides an API needs to be created along with necessary classes and interfaces for Marble. Andrei Duma, another Summer of Code participant, is developing Marble’s ownCloud application while I develop the client side.
You can follow Andrei’s work on GitHub.
We first started implementing route synchronization. It is easier than bookmark sync, because bookmark sync requires merging and conflict handling. So far Marble can upload routes to cloud, display a list of cloud enabled routes and download routes from cloud.
You can see Marble’s new cloud buttons residing right next to the save button. The one on the left uploads the route currently displayed to cloud while the other one brings up cloud routes dialog.
This new dialog lets users view routes on their cloud. Users can download the ones they like or uninstall routes from their devices by simply clicking to “remove from cache”. If they want to get rid of the route completely, they must press to “remove from cloud” button after removing the route from cache.
The next step will be implementing an ownCloud account manager. For now Marble communicates with a dummy API but after the creation of account manager, testing will be made with the real API which Andrei develops.
I am Adrian, a Romanian first-year student majoring in Computer Science at Imperial College London. I have recently been accepted to work on a KML Editor feature for the Marble Virtual Globe as part of KDE and this blog is where I plan to regularly post updates on the progress of the project.
In case you are not yet familiar with Marble, you can check out its website here for more details. In this post, I will try to talk more about why editing support for KML is needed in Marble and touch on some general points regarding the specifics of the project.
KML (Keyhole Markup Language) is a file format derived from XML and widely used for representing geographic data and annotations. Similarly to XML, it uses a tag-based structure with nested elements and attributes, fairly convenient to both understand and process for serialization. Since 2008 it has become an international standard of the Open Geospatial Consortium and popular Earth browsing pieces of software such as Google Earth have become reliant on it.
Marble’s support for KML has evolved over the years, as it is now used extensively for internal representations, the display of imported files and full support of data serialization might be completed with the next stable release already. Yet creating KML files can only be done for some few special cases, and not in a simple and intuitive way.
Since most related markup file formats are internally handled as KML, developing thorough support for sharing data processed in Marble in an open standard that has taken off under the influence of Google would provide the foundation of an universal editing mode, which would unquestionably help popularize Marble and provide the basis of easy integration on a large scale with other international standards.
At this point, it should probably be clear enough why the editor mode would help improve Marble and we can talk a bit about what the project will actually consist of. More specifically, the planned editor mode will primarily focus on adding support for creating and editing the following features:
More details on each element and its implementation details will be posted as the project progresses and I can actually show my work.
I don’t want to let my first post become too boring, so I just hope that now you are familiar with the project. Next time we will probably talk about setting the project up and its incipient stages or even get so far as to talk about the first implemented feature.
See you soon!