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.