OpenOrienteering is a project developing a collection of tools which help with the creation of orienteering maps and the organization of orienteering events.
Posted on 10 January 2012 by Thomas Schöps
As usual, here comes a small update about development on the Mapper program. A feature which I finished recently is the point symbol editor. It should already be usable to define all point symbols in the ISOM/ISSOM standards.
The screenshot shows a demo symbol containing one line element (black), one area element (orange) and some point elements. On the left side, there are some general settings which are the same for every symbol type. In the lower left part, there are the symbol type specific settings. For point symbols, this is currently only one: whether the symbol should be rotatable or always oriented to north. In the middle of the window, there is a preview of the symbol. The bar at the bottom allows to load a template and to center it on the coordinate system origin, either using its bounding box or using its center of gravity - something that could be useful to draw some of the orienteering point symbols. On the right side is the point symbol editor. Here, the elements the point symbol consists of can be defined. The element coordinates can either be entered at the bottom or set by clicking at the preview in the middle. For lines and areas, there is also the possibility to use bezier curves (not shown here).
That’s it already for this time. My plan is now to continue with the symbol browser and the other symbol types, after that the drawing tools can be implemented and the program will hopefully slowly start to become usable for map drawing.
Posted on 07 January 2012 by Thomas Schöps
Here comes another small update about some of Mapper’s current features. The first one for today is color definition for map objects:
Yes, that’s not too exciting, but necessary. Editing in this table works inline like in a spreadsheet program, colors can be defined by specifying CMYK or RGB values. Colors higher in the list will be drawn on top of the lower colors.
One thing that probably would be useful is some sort of color management which could be used to make the on-screen colors appear exactly as they are printed later. But I have no experience with this, neither in implementing it nor in even just using it, so I don’t know how hard that would be. Maybe I will look into it later, but for now it is more important that map drawing works at all.
The second feature for today is drawing on templates:
It allows to paint directly on raster images loaded as templates, so in mobile use the program can be used like a drawing board. Of course it will also be possible to draw map objects directly, but sketching like this has some potential benefits:
While having more objects on the map will degrade performance, this does not happen when sketching on a template. This could be important for the use on mobile devices.
Erasing drawn lines or parts of them is intuitively possible by painting over them in white, the “eraser color”. Map objects would first have to be selected, cut into pieces, and then the correct piece deleted.
The setup for the sketching is still a bit more cumbersome than necessary though. At the moment, if you do not want to destroy your base map images when painting and want to be able to erase what you have drawn, you have to create a separate transparent image template, load that on top of the base maps and use it for drawing. For the future, an idea is to offer a separate “Sketch” template type which would be a sketching canvas that grows automatically to cover the area which is painted on.
Currently, I am working to implement the first map symbol type, point symbols, and an editor to define such symbols. This is a lot of work and it seems that for every item on my “to do”-list that is accomplished, two new items come to mind. At least it is already possible to create the simplest of the point objects. More about it will come with the next update.
Posted on 04 January 2012 by Thomas Schöps
From now on, I will push code changes to a public git repository so everyone can have a look at the code. You can download it like this:
git clone git://git.code.sf.net/p/oorienteering/code oo-mapper
Some more or less technical details: The program is written in C++ using QT. While developing, I only test on Ubuntu linux, so the code probably won’t even compile with Visual C++ on Windows without some changes. The license is GNU GPL v3. At the moment, the code is only interesting for programmers, as it is not possible to do anything useful with the program yet. Ok, actually it could be abused as a simple painting program or gpx viewer, but that is not really its purpose.
You might be wondering how C++ with QT is supposed to work on Android. If so, check out the “Necessitas” project. It is still in alpha stage, but I hope that it will work well enough.
Posted on 04 January 2012 by Thomas Schöps
Among the few planned features of OpenOrienteering Mapper which are already working are templates and georeferencing of them. Two types of templates are implemented: image templates which are normally used to display base maps and, since yesterday, also GPS templates.
The supported formats for image templates are those supported by QT: bmp, gif (read-only), jpg, png, tiff and a few obscure ones. If someone needs support for another format, it would be very easy to extend this, for example using FreeImage. For GPS tracks, currently only gpx is supported. At first I looked for a C++ library which supports the loading of GPS track files in various formats, but did not find anything which seemed really suitable. The closest was using GPSBabel as a library, but it seems like it is not intended to be used like this. So, for now I implemented a simple gpx loader myself. To convert the coordinates from the gpx file, consisting of latitude and longitude on the earth ellipsoid model, to map coordinates, an orthographic projection is used. The center of the first loaded track is automatically suggested as the origin for the projection, but this can be adjusted.
All types of templates can be georeferenced. This means adjusting their transformation so multiple templates, or a template and the map, fit together. It is done by specifying two or more corresponding points (“pass points”) on the template which should be moved and the reference it should be adjusted to, then a transformation for one template can be calculated which makes these points match as good as possible. The program currently uses only scaling, rotation and translation (no shearing) as transformations to do this and no deforming of templates is done.
Following is a screenshot showing an image and a gps template. The image is the green background containing the red line, which was generated from a gps track using an external program, the gps template is the thin purple line showing the same track loaded directly. The picture was taken after I implemented the gps templates, so I wanted to compare the two images of the track to see if the implementation works correctly and they are identical. To be able to do that better, I added four pass points to the directly loaded track which are shown as connected red and green crosses. This is the state before applying the georeferencing:
After clicking on “Apply georeferencing”, it looked like this:
Seems to fit perfectly :-) The red and green pass point crosses are now almost on top of each other, showing that the pass points are consistent. The error in meters could be read from the georeferencing box on the left. If something went wrong, it is always possible to undo the transformation by unchecking “Apply georeferencing”, moving the pass points, deleting some or adding more, and trying again. The points can even be edited while the transformation is active.
Note that while in the screenshot only a track is shown, displaying waypoints and their associated names from gpx files is also supported. And if another gpx file is loaded, it will automatically be transformed to match with the first loaded track.
A possible addition to the templates for the future would be the ability to load digital elevation models directly, without having to use an external program to visualize them first.
Posted on 01 January 2012 by Thomas Schöps
The year 2011 is over and it is time for a status update here. My semester abroad is finished and due to different semester times my next semester starts in more than three months, so I’ve got a lot of free time now. Time to party? No. Time to work! ;-) So I am going to announce the next project I am working on, and this time it is a bigger one:
… is a program which aims to replace OCAD, the current standard for drawing orienteering maps. Sounds like re-inventing the wheel? Here are some of the reasons why I think that this is important:
OpenOrienteering Mapper will of course be an open source program and so it will be freely distributed. Clubs do not need to pay expensive license fees anymore and can spend the money for more useful things, e.g. making maps.
If all goes well, the program will be able to run on Android devices and take advantage of their GPS and digital compass functionality. This way, lots of cheap hardware will be available for mobile use.
The program will be multi-platform and work well on Windows and Linux. A Mac port would not be a big effort either. As I do not own a Mac I will not provide that directly though, but any interested person can grab the source and create one.
Currently, the program is still in an early state though. At the moment, it is already possible to define map colors and to load and georeference base maps, and to draw on base maps (intended for use when surveying with a mobile device). Map drawing is not possible yet. So, why do I blog about it if the program is not ready yet?
To generate interest: if you are an orienteer and programmer and think that this is a useful project, you are invited to join it!
To get feedback: if you are a mapmaker and intend to use the program when it is ready, you may want to give some feedback on what I present here. Of course I can in no way guarantee that wishes will be implemented, but it is always useful to hear other opinions.
For self-motivation ;-)
I hope that you agree that this is a useful project - if not or if you have other things to say about it, feel free to leave a comment here.
I plan to blog about the bits which are already working part-by-part the next days and, after that, to keep you updated on the development. So, let’s get back to coding for now … ;-)