Today comes just a short progress report to show that we are still alive
Development is currently going on slower than before, but apart from the usual bugfixes and smaller improvements some features have been added since the last update nevertheless. These are:

• The cut tool to split lines in two, remove segments from lines or cut areas into two parts
• The ‘cut hole’ tool to cut holes into areas
• Translation infrastructure and German translation covering most of the currently existing texts, contributed by Kai Pastor

Since the release of the alpha version of OpenOrienteering Mapper some progress was made, so it is time again to present the latest advances. One thing I’m particularly happy about is that various developers already contributed patches to the program. Most notably Pete Curtis joined the project and has been doing great work on file import/export. This of course includes the most requested feature, conversion to and from ocd files (currently, version 7/8 only). You can see a work-in-progress screenshot of the ocd import here:

Other than that, work is going on to implement the essential map edit operations. Since the release of the first alpha version, the following features have been added:

• Writing and editing text objects
• Adding / Removing points from paths with the edit tool
• The rotate tool
• The path connect tool

And, of course, a lot of bugs have been fixed.
The release of the next alpha version is planned when ocd import (and maybe export) are working well.

In the meantime I built the ISOM 2000 foot-o symbol set in OpenOrienteering Mapper, except the overprinting symbols, because there is no course setting support planned for the near future (I recommend Purple Pen for that task). All of the symbols should display correctly, apart from any mistakes. Working with the program to create the symbol set allowed me to find and fix a lot of bugs and usability problems.

In addition to that, it is now possible to draw point and path objects on the map and there is a basic edit tool to adjust their control points. All of the tools show a neat live preview of the objects that are drawn. You will soon be able to try it yourself easily because I plan to release a first preview version for Windows the next days (well, I think that I should at least try to counteract the announcement of the OCAD 11 beta a bit ). There are only a few things missing that I want to add beforehand. For now, here are two screenshots:

Drawing a path with half-transparent live preview

Editing a path, also with live preview

Initial support for line symbols is now finished. In theory, all types of lines described in the orienteering map standards should be supported. On the other hand, there are still some possible setting combinations which do not give sensible results. Here are a few screenshots showing different possibilities:

Dashed lines with end symbols (arrow caps) and mid symbols (yellow dots)

Rock faces!

Using mid symbols without a line to create e.g. vegetation boundaries

At the top: my personal nightmare, dashed bezier curves with dashed border lines

One thing to note about the line symbols is that the orienteering map standards just specify ‘ideal’ lengths for the dashes and breaks of the line types. There are no recommendations for how to handle the case where these ideal lengths do not add up to fill a line exactly. The simplest way would be to use the ideal dash and break lengths and just cut the line off where it ends. This will look bad at one line end in the most cases, so a solution which scales the dashes and/or breaks to fit into the line should be preferred.

OpenOrienteering Mapper currently does it like this:

• Only dashes are scaled, the breaks are always of the same (ideal) length.
• When a dashed line segment is created, to determine the number of dashes to show, first the dash counts for the two ideal line lengths which are closest to its actual length are calculated. From this, the deviation of the ideal length of the dashes themselves when scaled into the real line is calculated for the two possibilities and the number of dashes where this deviation is smaller is chosen. In other words, when determining the number of dashes for a line, the program tries to minimize the deviation from the ideal dash length.
• Special case: if the length of the segment in question is smaller than the length of the ideal segment with two dashes (or dash groups) minus the maximum amount of deviation from the ideal dash length (calculated from the point where the dash (group) count switches from two to three) for every dash, the line is considered too short for dashes and displayed as a continuous line.

This seems to look okay in most cases (as can be seen in the screenshots above). But in the case where multiple dashes are grouped together (with the intent of having a different break length inside groups than outside), the length of the line it takes until the dashes show up feels rather long, as can be seen here:

This of course assumes that the system works correctly, which I am not completely sure about
It would be possible to specify an arbitrarily lower limit for the dashes of lines with dash groups. But that is the problem I see with it: it would be arbitrary.

Does this system sound reasonable? Do you have any ideas for improving it? Feel free to leave a comment.

Recently, I’ve made some good progress on the symbol types, so it’s again time to present the newest features here. The current status is that all planned symbol types except lines are now more or less finished, this means points, areas, texts and ‘combined’ symbols. It does not mean that it is possible to draw objects with these symbol types on the map yet – the drawing tools will be another big piece of work – but it is now possible to define the various symbols having these symbol types, so it is almost possible to start building the IS(S)OM symbol sets.

Because a picture says more than a thousand words, here is a screenshot of the area symbol editor:

It shows a test symbol with black background and various fill patterns consisting of line symbols and rows of point symbols. The upper left part of the window contains the general symbol settings, in the lower left part the area settings can be adjusted. The preview in the middle shows the area symbol at the top and all point symbols which appear in its fill patterns at the bottom. These point symbols can be edited with the point symbol editor on the right.

Next is the text symbol settings window:

I couldn’t resist
Apart from that, the settings contain the standard font settings one would expect.

The last ones are the combined symbols:

This symbol type allows to combine two or more line or area symbols into a new one. For example, with this a building outline and a building area filling could be combined into a single ‘building’ symbol which makes it more convenient to use.

And finally, there is now also a symbol browser where the defined symbols can be selected:

The tooltip shows the symbol number, its name in bold and after F1 has been pressed the symbol description is blended in at the bottom. In contrast to OCAD, the symbol icons used here are not separate raster images, instead they are generated directly from the symbol properties which makes them scalable and removes some effort from defining symbols. If it should turn out that this leads to too indistinguishable icons, some settings for them could be introduced.

That’s it for now. My plan for the next developments looks like this: first, I want to finish the line symbols and some basic drawing tools, so objects can be placed on the map. Then, I want to create a first preview build of the program for Windows which makes it easier for you to try it out and give feedback. Let’s see how long this will take. Bezier curves in combination with dashed lines having dashed border lines whose dashes need to be synchronized on both sides could be really painful

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.

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.