Archive for the 'Kosmos' Category

Published by breki on 08 Jul 2008

Kosmos 2.0 - "Illegal Hotkey" Fix

Yesterday I had a few reports that Kosmos GUI breaks down right at the start, reporting “System.ArgumentException: Illegal hotkey ‘Ctrl+N’.” error. I could not reproduce this problem, but I think it occurs only on non-English Windows, probably because the Microsoft code I used to parse hotkeys expects different forms of hotkeys for different languages. I tried to change the UI culture for the application and test if the error occurs then, but to no avail.

I decided to fix this by implementing my own parsing logic for hotkeys. Again, I could not test if this now works for non-English Windows. So please download the latest package (2.0.508.0) and let me know if this problem is solved.

Published by breki on 07 Jul 2008

Kosmos 2.0 Is Here At Last

After almost 5 months of development, I can now announce that I’ve just released a new version of Kosmos. I’ve talked about it several times, although my blog posts have been reduced to practically zero - I’ve been so busy with Kosmos that I just didn’t find the time to write.

NOTE: before proceeding I should warn you that I consider this release to be in beta stage. I spent the last month killing bugs in Kosmos, but since a lot of new functionality was added there are bound to be quite a few bugs still lurking around. If/when you encounter them, please report them on the Kosmos OSM Wiki talk page.

Download

You can download the latest version from here. I’ll be also publishing the source code in the next few days.

So what’s new?

Tabbed Document Interface

First of all, the GUI interface has been completely rewritten. Kosmos GUI now uses an tabbed document interface (TDI):

image

As you can see from the screenshot, the user interface is somewhat reminiscent of Visual Studio. You have a Project Explorer through which you can edit the project file. There is the Properties window which displays properties of the currently selected project or data file. There is also the Activity Logger window which shows the activity Kosmos is performing.

Of course, there is the Map window with the familiar Kosmos-rendered OSM map. You can also look for new maps using the Web Map window which is able to display most common Web maps (OSM, Google, Yahoo, Microsoft).

Downloading OSM Data

Kosmos can now download the OSM map data from the OSMXAPI server. So in theory you can now generate a map without any additional tools. Be warned though: OSMXAPI can be quite slow sometimes, especially if you choose to download large map areas.

GPX Support

Kosmos now has the ability to download GPS data from a GPS unit and display it on the map. You just need to have gpsbabel software downloaded and saved somewhere on the disk.

Relief Contours

I integrated the Srtm2Osm tool into Kosmos GUI so that users can generate relief contours for any map area:

image

Imagery From Landsat And openaerialmap.org

Another nice feature in Kosmos 2.0 is the ability to download free satellite imagery from Landsat and openaerialmap.org sites:

image

Tile Server

The tile server (launched from the Kosmos Console) is now able to render all of the data specified in the project file. This means that you can now render tiles which contain shaded reliefs, satellite imagery, GPX tracks, elevation contours.

Other Stuff

There are lot of other improvements which I will describe on the Kosmos OSM Wiki pages in the next days.

What’s Missing

This is not the end of Kosmos development, far from it. I still have quite a few ideas I want to introduce into Kosmos. I realize that a lot of things are still missing - I have a “to do” list that is growing day by day. Hopefully future releases will have even more cool features. So be patient… And do send me some feedback, critiques and ideas :)

Published by breki on 01 Jun 2008

Kosmos 2.0: First Screenshot

I haven’t been posting anything for at least a month. The reason is that I’ve been quite busy with the development of the new version of Kosmos.

I’m happy to announce that the development is in its final stages. Most of the new features that I’ve planned for Kosmos 2.0 have been finished, now I’m mainly working on bugfixing and final touches. I expect the first release to be sometime this month (June).

Since I haven’t released any new stuff in months, today I decided to at least publish the first screenshot of the new user interface:

Kosmos2.0

As you can see, Kosmos 2.0 uses the tabbed document interface (TDI). On the left you can see the Project Explorer window, which can now be used to edit the project - no more manual text-editing of XML files. Notice the project tree view now supports showing of GPX files (which can now be downloaded directly form the GPS unit) and elevation contours (which can be generated inside the Kosmos GUI). On the bottom is the logging window, which can be used to track what Kosmos is doing. TDI itself if fully configurable, so you can move, resize or hide windows any way you like.

You can track the progress of the development on the Kosmos OSM wiki page.

Published by breki on 21 Apr 2008

White Facade - Fluent Interface For Writing Tests Using White

A few days ago I wrote about my first experiences in using White. I mentioned I wanted to create a facade around the White API in order to avoid constantly retyping the same code for common use cases. Since fluent interfaces are in fashion now, I decided to create a fluent facade. Just joking, of course.

I’ll present the facade through a few tests of a Kosmos GUI, which is currently under construction. Kosmos GUI is a MDI application for displaying maps from OpenStreetMap geo data. You have to load a Kosmos project, which contains information about where to find the data and how to render it. So after starting the application, the first user action would typically be to open the project:

Kosmos1

After clicking the File|Open Project menu item, a dialog for selecting the Kosmos project file appears:

Kosmos2

One you have selected the project file, a progress box is shown with an option to cancel the operation:

Kosmos3

If you let it finish, a map appears and some additional menu items are now available:

Kosmos4

Test Code

Here’s a sample test case which goes through the above steps:

[Test]
public void OpenProject()
{
   facade.ClickMenu ("File", "Open Project…")
      .FileDialog ("Open Kosmos Project File",
         @”D:\MyStuff\projects\OsmUtils\trunk\Data\Kosmos\KosmosProjectExample1.xml")
      .MainWindow ().ModalDialog ("Loading Kosmos Project")
      .MainWindow().Menu ("View", "Zoom In").AssertIsEnabled (true)
      .ClickMenu ("View", "Zoom In")
      .ClickMenu ("View", "Zoom Out")
      .ClickMenu ("View", "Zoom All");
}

After loading the project the test case executes some of the zoom functions available in the menu. And here’s a test case which cancels the project loading (and then checks that the View|Zoom In menu item is still not enabled):

[Test]
public void OpenProjectCanceled ()
{
   facade.ClickMenu ("File", "Open Project…")
      .FileDialog ("Open Kosmos Project File",
         @”D:\MyStuff\projects\OsmUtils\trunk\Data\Kosmos\KosmosProjectExample1.xml")
      .MainWindow().ModalDialog ("Loading Kosmos Project").Button ("Cancel").Click()
      .MainWindow ().Menu ("View", "Zoom In").AssertIsEnabled (false);
}

Hopefully the code is self-explanatory. The basic idea is for the facade to remember the current window or other UI element to perform actions on. You can change the active window at any moment. The facade is also supplied with some basic assertion methods useful in the test code (they throw InvalidOperationExceptions, so you can use them with any unit test framework).

Oh I almost forgot. This is how you instantiate the facade:

WhiteFacade facade = WhiteFacade.Run (applicationFilePath);

And if the facade does not offer enough for you, you can always access the underlying White’s Application object through facade.Application property.

Download

You can download the latest version of the WhiteFacade class from here. I have to warn you though: the class is in its infancy and will evolve through my effort on testing Kosmos GUI. It provides only for some basic use cases, but I think those common cases represent the majority of the GUI test code. I just wanted to give you an idea on how to make writing GUI test code as painless as possible.

Published by breki on 19 Apr 2008

Using White To Test Kosmos GUI

After a few weeks of work on my new framework for multidocument interfaces called BrekiViews (yes, I know I promised to write a little about it, but I just didn’t have enough time and concentration to put the brainstorms in my head into some coherent words) and refactoring Kosmos code to use it, I’m finally able to show some basic stuff in the new Kosmos GUI application. It’s all pretty simple at the moment, I got just one menu item working: File | Open Project. But I wanted to use this opportunity and start using White from ThoughtWorks to write automated GUI tests, since I was looking forward to trying the White out.

Documentation (Or The Lack Of It)

Unfortunately, the first impressions aren’t that good. The worst problem is lack of documentation. There are some pages written on the project’s CodePlex page and I also stumbled on a few posts which have some more examples on how to use it, but in general the API is undocumented. NDoc documentation that comes in the latest release just contains the API reference, without any human-generated documentation. It even states that it’s based on .NET Framework 1.1, which was obviously autogenerated and is probably wrong, since the API includes generics. I haven’t checked the source code directly though, maybe there is something there.

Yes I know, it’s an open source project and I shouldn’t expect too much, but I still think that such a project for which the whole purpose is to be used through an API should contain at least some documentation. Otherwise you spend a lot of time experimenting with the API to achieve the results.

Keyboard Problems

Like most other UI testing frameworks, White too suffers from quirks. I wanted to start the “Open Project” menu action using the keyboard shortcut, so I tried with:

mainWindow.Keyboard.HoldKey (KeyboardInput.SpecialKeys.CONTROL);
mainWindow.Keyboard.Enter ("o");

Which ended up forcing me to restart the computer, since the OS started acting very funny, as if the Ctrl key was still being pressed. I guess I should have added

mainWindow.Keyboard.LeaveKey (KeyboardInput.SpecialKeys.CONTROL);

to unpress the Ctrl key, but I’m not sure, since I couldn’t find any documentation on using the keyboard in White. Anyway, a helper method that would accept a shortcut as a string (something like KeyboardInput.Press (”Ctrl+O”) would be very helpful).

Clicking The Menus

After abandoning the keyboard approach, I tried to start “Open Project” by clicking on the menu item. I did some experimenting and finally managed to write a basic test, here’s the whole test fixture:

   [TestFixture]
    public class BasicTests
    {
        [Test]
        public void OpenProject()
        {
            Menu fileMenu = mainWindow.MenuBar.MenuItem ("File");
            fileMenu.Click();
            Menu openProjectMenu = fileMenu.SubMenu ("Open Project…");
            openProjectMenu.Click();
        }

        [SetUp]
        public void Setup()
        {
            application = Application.Launch (@”..\..\..\Kosmos.Gui\bin\Debug\Kosmos.Gui.exe");
            mainWindow = application.GetWindow ("Kosmos GUI", InitializeOption.NoCache);

            Assert.IsNotNull(mainWindow);
            Assert.IsTrue (mainWindow.DisplayState == DisplayState.Restored);
        }

        [TearDown]
        public void Teardown()
        {
            application.Kill();
        }

        private Application application;
        private Window mainWindow;
    }

White Facade

From my experience with other UI testing frameworks, if you intend to do more than a few simple UI tests it is a good idea to create some sort of a facade around the testing API. This way you simplify the interface to common use cases you typically use and eliminate any nasty quirks (like memory or resource leaks). Bil Simser has done something to that affect for White, although I don’t support his views on (not) using Setup and Teardown methods in unit tests.

Even better: why not implement a fluent inteface facade? Something like

WhiteFacade.Run(kosmosGuiPath).Press ("Ctrl+O")

or

WhiteFacade.Run(kosmosGuiPath).ClickMenu ("File", "Open Project…")

would be much nicer than the above code, don’t you think? Okey, I’m oversimplifying, I know :), but I will try to do something in the direction of a fluent interface facade, since I don’t intend to abandon the White just yet.

Published by breki on 29 Mar 2008

The Future Of Kosmos

I haven’t been posting for a long time and since some people already asked me what was happening I decided to write a post about my ideas and activities around Kosmos.

I have been pretty busy working on a short project for my company during the past month, so I haven’t been able to do any real work on Kosmos. This coincided with my decision to finally make a big step in redesigning Kosmos.GUI to use the multiple/tabbed document interface. The main reason for this is that the features I want to add to Kosmos would be very difficult (and user unfriendly) to implement with just simply using dialogs.

Features

So let’s first talk about candies. The ToDoList I use for Kosmos is quite long, but I’ll boil it down to things which users will probably find most interesting:

  • Downloading OSM data using Osmxapi: now that Osmxapi supports relations, this should be a really nice addition to Kosmos.  You’ll be able to download datasets larger than by using JOSM.
  • Project explorer: a tool window which will contain a list of all files loaded into project (OSM, GPX, bitmaps…). So no longer will you have to edit the Kosmos project files manually in text editors.
  • Viewing GPS data: you’ll be able to view GPX traces directly in Kosmos. Later maybe even downloading directly from GPS units will be supported.
  • Generating elevation contours for a selected area: I already added the code from my Srtm2Osm project to Kosmos. The issue is how to store the contours on disk - as OSM files or in binary format? Probably binary format, because of the data size.
  • Logging window: all major Kosmos activity will be displayed in a special window.
  • Searching for data
  • Exporting geo-referenced bitmaps
  • Importing geo-referenced bitmaps: maybe even support for WMS?
  • Built-in rendering rules editor: well at least a way to turn on/off certain rendering rules would be nice. Full-blown editing? Maybe, but it’s not a high priority.
  • OSM data editing: I’m not very keen on entering this territory, since I think it is already covered well enough by JOSM and other OSM editors. But I think the idea should at least be mentioned.
  • 3D relief (using SRTM data): this would be great, although it would require a lot of work, so I’m leaving it at the end of the list. Luckily I did something similar a few years ago in DirectX, so I would be able to at least partly reuse the code. But don’t expect GoogleEarth here ;)

 

Hiking Extension

Since I do a lot of hiking in my spare time I am also toying with the idea of using Kosmos as a platform for more specialized software for hikers. A way back I already did something in that direction, so the code could be reused. There is a special page on OSM Wiki discussing ideas on an open source application for hikers (OpenTrail) but I did not see any progress since January. My idea is to introduce some of these ideas into a some sort of an extension for Kosmos.Gui sometimes in the future.

The basic idea is to provide the hiker a tool to plan a hiking route (based on OSM and elevation data). The route could then be printed, including its estimated elevation profile. You could also let the program choose the route based on the distance, steepness etc.

Current Development

Currently I’m working on some sort of a simplified composite application block (CAB) which I will probably then introduce into Kosmos, once the block’s design has been stabilized. The block is intended to separate the "business" logic from the actual GUI implementation and to provide certain facilities common to all GUI applications:

  • Common GUI patterns, like menus, toolbars, status bars, common dialogs
  • Event broker - a centralized and unified way to handle events in the application
  • Asynchronous (parallel) execution
  • IoC containers support, so that everything could be defined through the configuration
  • Pluggable infrastructure.

Without such a block it is very difficult to implement a more complex GUI application. I already have certain things implemented and I’ll be writing more about the progress and the reasons to roll my own CAB.

Published by breki on 22 Feb 2008

Kosmos v1.12

crete.png

Hello everybody, after fixing problems with my failed hard disk, I finally managed to produce a new version of Kosmos. So what is new:

  • Coastline processing has been considerably improved. Kosmos should now be able to fill the sea polygons in most situations, not just for isolated islands.
  • Kosmos can now display an elevation coloring raster for a given map area (see the above example of the Greek island of Crete).
  • I added a high-speed drawing menu option in Kosmos GUI. This will render the map more quickly using a lower quality of rendering. Can be useful when you want to quickly move around the map.
  • JOSM download bound boxes can now be displayed in Kosmos GUI.
  • A new TopLevel option for rendering templates was added which enables you to render certain features above all others, regardless of the layer value of an OSM element.
  • Kosmos now officially runs in Mono (with some problems, however).

As always, visit the Kosmos Home page for the download link. Also visit Kosmos OSM Wiki pages for more information about new features.

Published by breki on 15 Feb 2008

Kosmos - progress on rendering coastlines

Kosmos coastline rendering

Since I didn’t do too much posting lately, I just wanted to write a status report on Kosmos development. I managed to improve the coastline rendering algorithm - now it should be able to render any kind of coastline situation, not just islands isolated from the mainland. On the top of the page you can see one example: rendering of Croatia’s gulf of Kvarner. I added relief shading to improve the looks.

How does it work? Kosmos uses bounding boxes recorded in OSM files which are written by JOSM to indicate boundaries of map data downloaded from the OSM server. Kosmos then slices the coastlines and creates polygons using those boxes.

The next step will be to extend coastline rendering support for data downloaded using other means, which does not necessarily hold bounding boxes. After that and after testing the algorithm to remove any glitches, you can expect a new version of Kosmos.

Published by breki on 10 Feb 2008

Kosmos 1.10

After two weeks of hard work, I am pleased to announce that a new version of Kosmos is here. Go to Kosmos Home for the download link.

New Features:

  • Wiki rendering rules table can now be split into several separate tables. This makes editing the rules more easy, since the rendering page can be organized into several sections and those sections edited separately.
  • I added a “subrules” feature for rendering rules: you can now specify a parent rule (say, highway=primary) and child rules (bridge=yes and *). Each child rule can have its own templates, so this enables rendering of bridges separately from other parts of the highway.
  • Added support for {{tag|key}} rendering rule selector. This selector will select all OSM elements which are tagged with the specified key, regardless of its value.
  • Added support for loading of bz2 and gzip OSM files.
  • Icon template now has HAlign and VAlign parameters. This helps when rendering features such as towers as you can now position the tower base right at the OSM node’s location.
  • Text template now has a tag fallback feature: you can specify more than one tag in the TagToUse parameter and Kosmos will use the first tag that exists for an OSM element. Example: TagToUse=nat_name;name will cause national names to be rendered for OSM features. If a national name does not exist, a common default name will be used.
  • Text template now supports drawing a rectangle around the text.
  • Print area can now be set. See below for more.
  • Added menu options in Kosmos.Gui for setting the print area to the current map view or to the whole map.

Bugfixes:

  • Kosmos now doesn’t fail when duplicate OSM elements are loaded. You can now load two or more adjacent OSM areas which share certain OSM elements.
  • Ways with missing nodes are now ignored by Kosmos. In previous versions Kosmos would fail if a way with missing nodes is loaded.
  • Fixed the backslash issue when generating tile file paths - this did not work on Linux.
  • Rasters are no longer lost when ‘Show unused…” options are toggled.
  • Page counts in the printing dialog are now refreshed when page settings change.
  • Printing page settings are now remembered when the print dialog is closed.
  • Added a workaround code for the MS bug (http://support.microsoft.com/?id=814355).
  • All GDI+ objects are now disposed of correctly. There was a resource leak in the previous version when creating new GDI+ pens.
  • Added handling and reporting of fatal errors in Kosmos.Gui.
  • Fixed a problem with loading obsolete user settings for Kosmos.

Setting the print area

You can now set your own area of the map you want to print. Just select the View|Show Print Area option and click on the blue rectangle to select it. You can reposition the rectangle by moving its corners. Its a little bit clumsy at the moment and also the selection indicators tend to disappear when you click somewhere outside the map. I haven’t yet found a good way of showing and hiding those indicators without redrawing the map. I will try to improve this for the next versions of Kosmos.

Kosmos source code

From this version on Kosmos releases will come together with the source code (Kosmos is now licensed under the BSD license), so I guess this makes it an open source project ;). The code documentation is quite patchy, I’ll try to improve this as the development progresses. Note that 3rd party libraries and tools are not included in the source ZIP - there is just too many stuff to include and also I doubt it would be possible due to license limitations of some of these tools.

What comes next?

I have to admit I’ve been neglecting Kosmos tile server, so now I will try to add some new features for it (including shaded relief in tiles, for example). Also, I’ll start working on a solution for the coastline rendering, so that the sea is filled blue in all situations, not just around islands. There is also some talk of making Kosmos run on Mono, we’ll see how that goes. Anyway, expect some new stuff in the following weeks :)

Published by breki on 27 Jan 2008

Kosmos v1.9 - printing maps, inspecting elements and more…

image

After a week of quite a lot of work, a new version of Kosmos is here. The list of new features:

  • Map printing dialog (see above image): you can now print your maps in whatever scale you like. Kosmos will calculate the number of pages needed and will show a preview of the printed map. Using a PDF printer driver (like the one here) you can even export the map into a PDF file.
  • OSM objects inspection tool
  • Kosmos now understands OSM relations: in this version, relations support is limited to examining multipolygon relations and knowing how to draw polygons with holes.

There are also some bugfixes and a lot of changes in the code. This means that there are probably some new bugs too. Please report them on the Kosmos OSM talk page.

In the next version of Kosmos users will be able to set the map print area (now the whole map is printed). And some other cool stuff too.

« Prev - Next »