Zen Garden
Creative Commons License photo credit: euart

As I mentioned few days ago, I’m currently finishing the Isohypse Binary File (IBF) functionality, which I intend to include both in the next versions of GroundTruth and of Kosmos.

The upcoming 2.5 version will probably be the last in the 2.* series. After its release I plan to do a major overhauling of the source code. The plan is not to add any major new features, but instead reorganize and clean up the code, since it has become more and more difficult to add new functionality in the existing code organization.


In order to explain this, let me first give a few historic facts. Kosmos 1.* series was a simple Windows desktop application which was started as a simple prototype for testing the map rendering concepts. It slowly grew fatter with new features, but the GUI code was very difficult to work with and almost made it impossible to create a user friendy interface. So a year ago (looks like I get these “ideas” each spring :) ) I decided this had to change, so I started working on a new GUI framework which would support multiple document interface (MDI) with runtime-configurable menu structure and actions. That’s how 2.* series started.

Separating The Domain Layer

Now that the code is old enough, I decided to take a look back at it. My conclusion is that there was too much emphasis on GUI and application infrastructure and that the domain logic (mainly OSM map rendering) was too intertwined with the rest of the code. Since I began reading the excellent Domain-Driven Design book (DDD) few days ago, this gave me a new perspective on things and convinced me of the need for the change.

The basic idea behind DDD is a principle of separation of the domain layer from the other layers in the software (user interface, application and infrastructure). In the case of Kosmos, the domain code would be the translation of OSM data into visual elements (and some other stuff). If this separation does not exist or if it is poorly enforced, all sorts of problems start to happen with the project. Including the types of problems I’m having now with Kosmos :). When you start mixing UI code, domain code and the application code, it is very difficult to track changes when you implement new features. Basically the software becomes a huge beast that cannot be comprehended even by its author :).

So my plain is to drag the map making code out and probably create a separate library for it. The added benefit would be that such a library could later be reused for other software too: instead of trying to fit everything and anything into Kosmos, there could be separate applications for

  • map editing (JOSM-style)
  • trip planning and analysis (something like this or this)
  • … you name it.


All Very Nice, But We Want New Features

Me too. I want to have a integrated visual rules editor, ability to view GPX data, routing (its actually already half-implemented, but it waits for the GUI support), 3D and a lot more. But in the present state of things, bloating the code even more in an unstructured way would only produce a lot of bugs and not a lot of working functionality. Which means that nobody will be satisfied with the results. I’d rather leave Kosmos as it is than to have a buggy-crappy tool.

So I guess the spring will be the time for some house-cleaning. Hopefully it will not take as much time as I spent in introducing Kosmos 2.0. So let me finish this post with a quote from Zen monks:

If you don’t have patience, if you can’t endure, well, don’t bother, because you won’t get very far.