Michael Foth and
Hans Stiegler, GER
The computing for the World-Championships 1995 in Germany will base on an experience of the last 5 years. Beginning with the new timing-system DAC535 at the World-Cup-Final in 1990, the system and the software were more and more improved to a system for getting fast results by a maximum of security.
The different steps of development by international events in racing, triathlon and orienteering, like Junior-World-Championship 1991 in Berlin, World-Cup 1994 in Quedlinburg, International-5-Days-Orienteering 1991 and 1994 in Uslar and the International-3 Days-Orienteering 1992 and 1994 in Simmerath, were always successful competitions, but we've found always points to make the system better. In the last years the most time of development were to find solutions for the mistakes the people can do by working with the systems.
So the systems has including now a lot of security-features for a lot of worst cases. Now we have a timing-system with the most security-features for timing-systems like this.
For the World-Championship in 1995 in Germany we are developing now the software-components for the different parts of administration and information. The following picture shows the structure of software for the World-Championship 1995 in Germany. The first version for information-system for the press were used the first time at the World-Cup 1994 in Quedlinburg. The base for this system for the press is a good one and we are knowing some facts to change and to improve for the World-Championship 1995 in Germany.
At the World-Cup 1994 in Germany we've worked with the first version of a speaker-software. The experiences with this software were a very good and we know now some facts to make it better for the World-Championship 1995 in Germany. The most problems we've got were with the power for the whole computing-system. A shutdown of the whole power had no effect to the timing-system, but the most of the computers for the press and the speaker broke temporarily.
The drawing of the events we are practising by computer since the Junior-World-Championship 1991 in Berlin. We're trying to make an attractive drawing by computer, but there is now no final decision how to make the drawing for the World-Championship 1995 in Germany.
There are some possibilities to get the split-times for the events. We have to differ the split-times for the finish-area and the split-times of all controls. We had a fast system for the split-times in the finish-area by radio-communications practising at the World-Cup 1994 in Quedlinburg.
We will have some other possibilities by using the punching-system of Regnly at the World-Championship 1995 in Germany.
The organisers are trying to get a electronic system for displaying split-times and results in the finish-area. Both solutions will guarantee a fast system of split-times and results for the finish-area and the information-system for the press.
The planned hardware-configuration will be a computer network based on Novell NetWare. All data and information are available on the central file-server.
The press will get an own working area with software for text processing and fax.
The speaker and the first timing workstation are equipped with battery
backed-up make notebooks. In this case the speaker and the timing-administrator
will get all information and results independently of the main power supply.
Return to the Table of contents
Marko H�kkinen, FIN
The following is a couple of reports from the "High Tech Orienteering Club", Korahdus in Finland. The reports appeared first on the electronic World Wide Web on Internet. Note that the reports are in reverse chronological order.
On 9 February '95, Korahdus gave a demo to invited guests in Pirkkola Sports Centre, Helsinki. What we were demonstrating was real time monitoring of an orienteer.
In the demo, the audience could see in real-time as Kimmo Liljestr�m (our guinea pig, currently ranked #2 in Finland) was taking his way through the course. Kimmo's moves could be seen on a PC monitor, inside the Central Park Cafe.
Our prototype monitoring system used in the demo was based on GPS technology. Placer GPS 400 from Trimble (courtesy of Geostar) was used as the roving receiver. Besides the GPS receiver, Kimmo had an RF modem and antenna (from Finnish Satel) and also a NiCd battery in his back. And of course, a Trimble GPS antenna mounted to his head. And a lot of wire. The total weight for Kimmo's load was some 1.5 kg (3 lbs). "The weight was OK -- less than a halogen system for night-o", commented Kimmo. "The snow was a bigger problem."
The real-time differential corrections were fed into the system from a Trimble Community Base Station. The PRC was sent over an RF link to Kimmo's back and from there the differentially corrected positional data was sent back over the same link. With this setup, Kimmo's position was shown on the PC colour monitor (from Digital) every two seconds -- also showing the direction where Kimmo's nose was pointing! The monitor also displayed the digital orienteering map to give the essential background for the monitoring system.
Everything worked OK. The only minor problem we had was the quality -- positional accuracy -- of the background o-map. As discussed in O-net, GPS positioning requires a very accurate base map. Now our base was not dead accurate, which in some parts of the demo course lead to minor disparities in the positioning: as Kimmo was running on a path, the monitoring system suggested that he was running 2-4 meters away from the path. This was a problem of the map, not the monitoring system itself. If the demo would have taken place on our Arvila-Hanttu map [field work supported by GPS, ed.], the positioning would have been dead accurate.
To demonstrate the capabilities of GPS technology, the course was not a Mickey Mouse course GPS-wise. There was heavy spruce cover over Kimmo most of the time and he also run through a tunnel twice, the signal staying alive virtually all the time -- even in the tunnel.
Korahdus believes that this was the first time an orienteer was successfully monitored in real time.
Korahdus plans to cut the roving equipment's weight down to 500-800 grams (1-1.5 lbs) during the next four months. We also plan to test RDS corrections (YLE -- the Finnish Broadcasting Company -- will start commercial RDS/DGPS in April). Next demo event -- with improved equipment and several invited elite orienteers -- is planned to take place near Helsinki in early June.
Jan Donner (ranked number 22 in Finland, representing OK77 from Kauniainen) carried a head mounted GeoExplorer GPS receiver (from Trimble) at the national event of Korahdus on 24 September '94. The receiver was fastened to a head lamp holder, weighing a total of some 500 grams.
The receiver was set to log fixes i.e. locations every second while Jan was taking himself around the 7.0 km course with 16 controls. The PDOP mask (Positional Dilution of Precision) was set to 8 (accuracy degrades as PDOP increases).
As can be seen in the map above (and below), the signal did not come through all the time; there are same gaps, lasting a few seconds. This was due to the fact that the PDOP mask was set very low (8), which caused the logging to be turned off whenever there were some minor obstacles on the line of sight (between the satellites and the receiver). It can be said now, that the PDOP mask was set too low (i.e. too tight); I suppose we could have tracked Jan's move every second by using a PDOP mask of something like 40-60 and still get very accurate data.
The orienteering club Kokkosenkyl�n Rasti ja Risahdus ry (or Korahdus for short) was put together in late 1993. Home town of Korahdus is M�ntyharju in the Mikkeli county, some 200 km north-east of Helsinki. The main goal of Korahdus is to serve as an R&D actor in the orienteering scene. So far, our main activity has been the development of mapping processes and organising orienteering events using new techniques. For 1995, we are going to focus on real time monitoring.
Each red dot represent Jan's location at the given second. As GPS signalling is largely based on propagation of time, also the time or t coordinate of every (x, y, z) position is available. This enables us to compute competitor's velocity all the time, over any distance or time (e.g. last 500 meters or 50 seconds, or a certain stretch such as from a control to another); thus we can e.g. analyse the runnability of different parts of the forest very accurately. I think this is a pretty important and notable fact to be considered when e.g. preparing for a major event; the method could be used in conjunction with national team training activities etc.
A map excerpt from between controls 12 to 13 also shows the effect of signal gapping. A magnified excerpt from control 13, Jan making a miss.
Jan's own words on the miss at 13: I came up from the slope as planned, but did not turn my head enough when entering the plateau in the green area (young pine plantation, dense, 6-8 meters tall). I rushed forward, hoping to reach the small depression and the flag but instead I saw a high cliff in front of me (some 20 meters away), looked at the map and turned around. Should have made a 180-turn, but didn't. So I hit the yellow area, ran to the corner and checked again. Didn't calm down enough and still made a small bounce to the wrong depression (north of control), and only then could I make the right correction. I'd say it was a miss of a minute or a minute and a half. There was nothing wrong with the map, I just wasn't concentrating on what I was doing.
Jan's miss cost him 1.15 (this can be seen from the intermediate times from a Regnly system and by counting the red dots of the GPS track).
During our event, the US troops were invading to Haitian territory and this helped us a lot; we didn't need to do the differential correction since the S/A code was disabled. The data from the receiver could directly be downloaded to a PC and the track be overlaid on the OCAD map. Thanks Bill!
A lot has been said about the accuracy of GPS. SSL (the Finnish orienteering federation), many mappers/orienteers/GPS professionals etc. here in Finland, and o-enthusiasts (in o-net) throughout the world have questioned the usability of GPS for o-mapping purposes. We let you decide yourself. See the maps, make a judgement and let us hear your comments. We are more than anxious to get your response.
For more information, contact: Marko H�kkinen, National Land Survey
of Finland, Geographic Data Centre, Development Services, PO Box 84, FIN-00521
Helsinki, Finland. Phone: +358 0 1545194, Fax: +358 0 1545454. Email: [email protected]
Return to the Table of contents
Finn Arildsen, DEN
This article looks into the benefits that event organisers and competitors alike enjoy by using a program package of co-operating programs developed for administration of orienteering events.
Programs in commercial program packages can share data among each other. They can either read each other's files or they are able to export data (either on the clipboard or as a file) in a format understood by the other programs.
Orienteers in Denmark use a program package for administration of orienteering events. The programs are developed by orienteers on a voluntary work basis. Although not as "glossy" as the commercial office packages, and still belonging to the archaic world of MS-DOS, these programs have been used at a majority of Danish orienteering events since 1990.
As most other orienteering programs anywhere else in the world, these programs are to a large extent tailored to the local modus operandi of orienteering event organisation. Although this may not directly apply to the situation in your country, I hope that the following can provide some useful inspiration.
The package consists of three programs:
Entries to a Danish event are forwarded through the local club. Typically, each club has a person who takes care of collecting the entries from members and sending one club entry form to the organisers [I believe this is the norm for the Nordic countries and Germany, while the practice in other countries is to enter as individuals or families directly to the organiser].
KLUB is a program to keep track of the club members' event entries. It maintains a database of the club's members, and a database of the published events with class information etc.
For each event, KLUB prints a completed entry form for the club, and produces an entry file on a diskette.
Club members' individual event entries are entered into the database, and the entry fees are debited to the individuals' accounts in the database.
For each event, KLUB prints a completed entry form for the club, and produces an entry file on a diskette. The club entry form is forwarded to the organising club.
One major advantage of being able to share data among programs is that you avoid the error prone and time consuming processes of re-entering the same data into more than one program, and entering output from one program into another.
So, along with the entry form goes an entry diskette with the same information as the form. All the organisers have to do is to copy the data from the diskette directly into the event administration program.
LOEB is the event administration program. It maintains a database of the competitor entries, clubs, and classes.
The program's functions are organised in three groups: Pre-Event, During-Event, and Post-Event.
In the Pre-Event phase, LOEB is used by the event secretary. An event is created and initialised in the database by entering the class data, such as class name, course name, length, number of controls etc.
The major part of this data can be retrieved and transferred from CONDES (see below) by means of a course data file.
Registration of competitor entries is the major activity in the Pre-Event group. At a large event this is a considerable task. However, using the diskettes produced by KLUB, registration is much faster and safer (for example is possible misspelling eliminated!).
When all entries are stored, the program performs the drawing of the start times and prints start lists and control cards.
One feature that is particularly appreciated among competitors is that the program prints control codes in the appropriate boxes on the control card. This is possible because the data transferred from CONDES includes the control codes for each course. Having the codes printed in the boxes makes checking the control codes during the race quick and easy.
In the "During-Event" phase, the program is used by the results team.
The main During-Event function is the input of competitors' finish times. Data entry is in pairs of competitor number and finish time. Data normally comes on slips from an electronic finish clock, or - more recently - on a serial link from a Regnly RTR-2 finish clock with bar-code reader.
Intermediate results are printed as data comes in, either as individual results on labels or as class listings. Normally, results are posted before the control cards are checked, so results posting is fairly swift.
Post-Event functions are mainly results printing in various formats.
LOEB supports individual events as well as multi-day and relay events. The same program is used for all of these event types. This means that the user interface is the same regardless of the type of event. The user does not have to get acquainted with a new program in order to organise a relay or a multi-day event.
CONDES is known by many orienteers in the world. It is a course setter's tool. Its main purpose is to produce control descriptions, and help the course setter keep track of the controls.
However, as gathered above, it is also a companion to LOEB and the two programs can share data.
CONDES maintains a database of controls, courses and classes. Controls are defined by the symbols that make up the control description, as well as a co-ordinate pair and a punch pattern. Courses keep a list of references (control codes) to the controls on the course. More Classes can share a course, hence a Class keeps a reference to a Course.
CONDES prints control descriptions for individual courses, as well as Farsta relay variations.
In addition to the control descriptions and the course data transfer to LOEB, CONDES produces master control cards for punch validation.
The software developers are not in immediate danger of running out of work. Users are very creative and generate numerous ideas for future improvements. The time required to implement all the ideas exceeds by far the possibilities of the developers, who use a fair amount of their spare time trying to keep pace with the requests.
For more information:
Finn Arildsen, 1775 Milmont Dr #E302, Milpitas CA 95035, USA, e-mail:
[email protected]
Return to the Table of contents
Bj�rn Heinemann, GER
An essential improvement in the administration of events
The enormous power of computer technique allows new ideas of storage and administration of big data stocks even in the field of Orienteering. It is the basis of keeping, passing and, consequently, efficient reuse of runners' data once gathered. Thus, for instance, runners' data once stored on diskettes can be exchanged between the organisers within certain territories. The O families are visible at a glance in most countries or territories so that operating with such a runners' database is the obvious choice. The advantage of such a procedure is evident:
Basically, this is not a new idea. Similar thoughts have been put into practice in various countries. Until now, however, these solutions based on a countrywide or territorial identification number assigned to each runner. Although this number warrants unique allocation, it is an additional feature. Of course, the use of such identifiers was an acceptable solution due to lack of memory in the early steps of computing technology. Today, the runner's name is the more reliable and simple variant of identification, due to certain redundancy. In addition, the person responsible for registrations in the club need not remember and administer a lot of artificial assignments of numbers. The solution having been proved for several years in Germany - especially in Saxony - just bases on the runner's name, his or her year of birth, sex, and club membership. These data warrants each runner's unambiguous identification. The runners' file includes:
Sorted by clubs, the organiser has just to click on the specific runner on the screen when being registered. The starting class will be assigned automatically in a sensible way, according to sex and year of birth. Only special demands concerning the start in another class must be entered.
Here you can choose a runner from the database and "copy" him to the event-data. The class is calculated automatically with the year of birth.
The file of runners can be exchanged on diskettes. Every organiser will extend the file by registration of new runners. Entering the ranking-list results enables quick evaluation even of complex ranking-list systems.
This procedure designed to facilitate the event administration has been
applying in Germany for several years, by means of different software solutions.
Now there is a database with more than 3000 runners.
Return to the Table of contents
Hans Steinegger, SUI
When registering for an event, Swiss orienteers are more individualist than those in other countries.
Registering (and paying) for an event is done by the individual runner and not by the club. And the individual runners gets his result list, not the club. Registering is done in a very effective way. The money is transferred to the postgiro account of the organiser and in the remark field of the transfer sheet the class and the club is given. By the way, everybody can participate, if he belongs to a club or not.
Unlike in other countries, where only the addresses of the clubs have to be stored, here an address for each runner is required. And those addresses, especially for the younger runners, change very frequently.
To reduce the typing work normally connected with this system a task force has been formed by the Swiss Orienteering Federation. The task is to create a runners data base, which is available for every organiser. Shortly before the event, the organiser gets the data on a disk and after the event he has to return a disk with all the modifications (address changes, additional runners). Thus the following organisers can profit from the work he has done.
The main new thing is a number for each runner. It should be short and easy to remember. The number should be permanently associated with the runner. The second part of the number consists of 3 characters built from the runners name. 2 characters are the 2 first characters of the last name and the third character is the first character of the first name. To distinguish runners which have identical characters here, there are 2 characters in the beginning, which build a number (from 1 to 26 * 26). This number is given by the orienteering federation. From the remaining digit one bit is the sex (male or female) and 3 bits form a control code. As changing two subsequent characters is one of the most frequent mistakes the control code must be able to detect these changes and is therefore not a simple checksum. The number for Heinz Tschudin could look like this:
AA4-TSH
TSH is extracted from the name Heinz Tschudin. AA is used to distinguish the different TSHs, 4 contains sex and control bits. Calculations made by the task force have shown that the number should have a capacity of over 100,000 runners.
The system will be introduced next year for the national events. It
could also be interesting for small events with no advance registration.
Return to the Table of contents
Bj�rn Heinemann, GER
In the framework of preparation and carrying through orienteering events, it is an ever and ever repeating pretentious and expensive task to create starting lists meeting all the requirements of runners and performers.
This results in the demand to solve this task properly by means of special administration programs for orienteering events. A clearly arranged analysis of the requirements was presupposed for the development of computer-aided solutions. In general, the process can be divided into two steps:
The OLP event organisation program offers solutions for these steps resulting from experience in preparing and performing O events in Germany.
Generally, the starting order in O competitions is defined by the random principle by drawing for numbers or by specific performance criteria (e.g. ranking list). In addition, it may be necessary to consider some more criteria, such as
Typically, OLP defines the starting order by means of a random number generator. It is even possible to modify this order manually by use of an appropriate function. This function, however, admits the starting list to be completely manually created - without using the random number generator.
Figure 1: Example of starting-time assignment. The survey of the starting field - in this figure unfortunately in black-white representation - can be shifted to the right over all starting times or down over all classes of the event. The colour screen displays "gleiche SZ auf einer Bahn" (same starting time on a course) red-coloured and "gleicher 1. Posten zur gleichen SZ" (the same first control at the same starting time) blue-coloured.
The case that two members of a club should never start one after the other can be performed by the "Trennung" function. Here, runners of another club are put between two consecutive runners of the same club as long as this is possible. Of course, should more than 50% of all the runners within a class come from one club, "vacant" spaces must be inserted manually to meet this condition.
The case that runners desire to start very early or very late in the starting order (e.g. for arrival or departure problems) can be noted in their entries. This note results in ordering them automatically into the front or back part of the starting order, respectively.
After definition of the starting order the second step will start. Mostly, this is the more complicated part in the starting-list generation: assigning the starting times. In doing so, a lot of different facts have to be considered. In most cases, the organisers want to have the field of starters not too wide apart, but not too dense, however, considering that several runners should never start on the same course at the same time. Of course, there are many facts to be considered, but not all of them can be mentioned here.
Computer programs allow to automate the assignment of starting times. This, however, is relatively complicated due to the variety of factors and their contradiction so that it scarcely could be performed to the organiser's absolute satisfaction.
This is the reason why it should be possible in any case to assign the starting times per class manually. To do this in a comfortable way, a graphical representation would be very useful.
The OLP program module for starting-time assignment shows all the runners by courses or by classes, respectively, in a diagram with starting times and classes. All runners of a class are shown in a line. The classes assigned to one and the same course are displayed in a block. If several runners start on a course at the same time they will be marked red-coloured. Runners who start at the same time on different courses with the same start control get a blue mark. Thus, possible problems on the courses can be stated easily.
Now, processing of starting times is quite simple. The field of starters of a class is considered as a block and can be shifted, stretched, or upset with the mouse. At first start of this module, shift of starting time and starting interval are assumed to be 0 minutes. When shifting, stretching, or upsetting, a small window next to the mouse cursor shows the first runner's starting time and the starting interval of runners in the respective class.
Naturally, the starting times for all runners can be assigned automatically, too. To do so, some basic parameters are necessary, of course: minimum and maximum starting interval, maximum starting time, etc. By means of this information, the starting times will be assigned to the runners steadily and without overlap, if possible.
Figure 2: Example of the number of runners per minute
After the starting times have been assigned in this way, checking the
starting density before starting is recommended. This is because accumulation
of runners in a certain period and, thus, problems in real starting can
arise. The module for starting-time assignment can display a kind of statistics
showing the number of runners per minute. Accumulation of runners at certain
times can be made out. Temporarily, however, many runners at one starting
time can be practically realised yet, but accumulation of runners over
a longer time will result in problems. These should be avoided by modification
of starting times for some classes.
J-J Cot�, USA
J-J Cot� is a very active mapper in USA. He has been using OCAD since it was first released. J-J Cot� was also on the WOC '93 course setter team. His review of OCAD version 5 appeared on the O-net some months ago.
- As one of the world's foremost users of OCAD (or at least one of the biggest loudmouths), the time has come for me to put in my two cents about what I think of version 5, as I've just completed my first map using it.
I felt that OCAD 3 was somewhat lacking, but that OCAD 4 was a marked improvement. The step up to OCAD 5 is even more dramatic. In various ways it seems like an entirely different program (because it is), and the changes are good ones. First of all, OCAD 5 runs under Windows, and thus has the general familiar look of a Windows application in terms of the dialog boxes and such. Happily, the move to Windows does not seem to have slowed OCAD down very much; it's quite tolerable on my 20 MHz '386.
In addition, the look of the map on the screen is different. The nominal colors used are much brighter than before (though there is a menu that allows you to change them), and the displayed thickness of lines seems to be different in some circumstances. The result of this is that the map looks more like a cartoon than before (on the screen), but the new appearance is very easy to get used to (it looks completely normal to me at this point). The other striking visual difference is that the cursor changes shape depending of which of several drawing or edit modes is selected (e.g. a little pair of scissors for "Cut").
The result of this is that the map looks more like a cartoon than before
Another change in the display that is a dramatic and welcome thing is the assortment of viewing scales. Where previous versions provided 20x, 5x, 1.2x, and "Overview" (which rendered the map as a vague brown smudge), OCAD 5 gives us 16x, 8x, 4x, 2x, 1x, 0.5x, and 0.25x. At all magnification levels all symbols are drawn, so it's now possible to get a pretty accurate view of the whole map at 0.25x. The 2x, 4x, and 8x levels all allow digitizing (fieldwork corresponding in scale to screen).
One important annoyance that has been cleaned up is the digitizer adjustment - it's now possible to waltz willy-nilly through various magnification levels and move the view screen around without the program forgetting the adjust information. In fact, it remembers the adjust information even if you leave the program or crash the system (which my flaky hard disk has been doing lately). And all magnification levels (plus move, redraw, and some other things) are available on function keys.
the program comes up the first time with the mouse active, and you can activate the digitizer from a menu item
Setting up to start drafting is somewhat more intuitive than before. Rather than telling the program the ratio between the fieldnote scale and the map scale, you explicitly tell it, for example, that the fieldnotes are at 1:7500 and the map will be at 1:15000. And if you decide that you want an enlarged version of the map, you can later tell OCAD to print at 1:10000, and the right thing will happen. The Adjust function for the digitizer allows you to specify as many as 12 points, and OCAD will determine the "best fit" adjustment to allow for the fieldwork being skew on the digitizer. (Personally, I'm into carefully lining up the fieldwork and adjust on exactly one point, but I can imagine that other people will really like this). There is no longer a separate configuration program - the program comes up the first time with the mouse active, and you can activate the digitizer from a menu item.
Level 0 smoothing presumably results in more points to represent the object, and thus bigger file sizes, but it doesn't seem to be much of a problem
Smoothing level 0 has arrived! O-net fans will recall my earlier complaints about the "smoothing" function in OCAD. Herr Steinegger is very good at listening and responding to feedback, and the smoothing can now be turned off completely. For those who have a steady touch with the digitizer, this a great help. Reentrants now come out looking the way they should, and the editing time is greatly reduced. Three smoothing levels are now provided (0, 1, and 2), and they are all useful (level 2 is good for large paved roads, for example, while 0 is de rigeur for contours). Level 0 smoothing presumably results in more points to represent the object, and thus bigger file sizes, but it doesn't seem to be much of a problem. The only snag that this has caused is that for long enough objects (like a contour that runs clear across the map), there would be too many points in the one line, so it's necessary to draw it in two or more pieces.
There are several drawing modes and several editing modes provided, all of which are selected from a toolbar. The two basic editing modes allow you to either drag individual points or whole objects around. Other modes allow cutting, or adding/deleting points, as well as rotating objects or properties of objects (like the direction of the white stripes in "runnable in one direction" green. Having these as tools is quite convenient, since, for example, if an area object needs to have several holes cut in it, it's not necessary to select "Cut" from the edit menu before every hole. When selecting a box-full of stuff to edit, all objects with at least one point in the box are now selected, unlike before when it was only objects entirely within the box. The drawing modes are Bezier, Ellipse, Circle, Rectilinear, Straight-line, and Freehand. Freehand is the normal mode that we're used to from previous versions. Straight-line is good for things like fences, and it results in an object consisting entirely of "corner points" (familiar from OCAD 4). Circle and ellipse are self-explanatory, but note that they have replaced the specialized "knoll" and "tank" symbols from OCAD 4 - you can now draw elliptical thickets directly, or arbitrary circular objects (very useful for logos). This is a nice enhancement, and the only thing lost is the "depression" symbol that automatically put in the tags, but this is no big deal. The ellipse tool does draw nice form-line knolls if the "form-line" symbol is used, by the way. The rectilinear drawing mode is an enhancement of the "building" symbol from OCAD 4 - you can now draw complex objects with sides that are forced to be either parallel or perpendicular to the first side drawn. This is an unspeakably fun tool to play with, and makes the drawing of large complex buildings a breeze. The last drawing mode is Bezier curves, which I'll address at the end.
The mouse or digitizer puck now has two useful buttons. The "left" button serves all of the old familiar functions, while the "right" button toggles between edit and draw modes. This saves a surprising amount of moving around on the screen. If you are using a digitizer, it is possible to change which of the four buttons OCAD considers to be "left" and "right".
The symbol menu... the whole notion of having a separate menu for each color, and having one color selected for drawing or editing is gone. Depending on how you look at things, either all symbols are together, or each is now its own separate thing. In any event, there's now one big scrollable symbol menu, and all objects on the screen are available for edit at all times. Customization has come in an a big way! OCAD 5 comes with a menu that basically corresponds exactly to the IOF spec book.
the IOF spec calls dark green "Vegetation: very difficult to run, impassable", I prefer to have it be called "Fight"
This can be modified in various ways. The first and most useful is that the menu can be rearranged by dragging the symbols around. While the IOF spec is set up in a logical way from the point of view of defining things, it's probably not the order that you want to draft the various symbols in. I used to have a sheet of paper taped to the wall in front of my desk with the drafting sequence on it, but now I just have the menu arranged in the appropriate order, and work my way down through it as I draft. The second thing that you can do is to change the names of the symbols. The names appear in boxes at the bottom of the screen that show what symbol is selected for drawing, and what object (if any) is currently being edited. So while the IOF spec calls dark green "Vegetation: very difficult to run, impassable", I prefer to have it be called "Fight". And thus anyone can change all of the names to their own language. The dimensions of the symbols can be changed if need be (perhaps contours up to 20% thicker? :-) and new symbols can be created, either line or area symbols from a pretty rich palette of parameters, or point symbols that can be carefully hand-drawn once, then selected, named, and stuck into the menu. So, for example, I have created a standard-length "slope line" (IOF symbol 104, but not included in the basic OCAD menu), and could easily create a brown triangle for DVOA-style charcoal terraces if need be. Such point features can have up to seven "component" parts when being drawn; more complex but less frequently used things like club logos can be saved as separate files and imported when needed (as before). And the symbol icons that appear in the menu can be adjusted to your heart's content. There are also operations that can be performed on all objects of a given type, such as making all of the boulder field triangles larger, or changing all of the medium green to light green.
TrueType fonts are now supported, which means that you are no longer restricted to the Helvetica and Helvetica-Bold typefaces. To create text in OCAD 5, you put a text item in the symbol menu for each text style that you'll be using. Any variation in size, color, or typeface requires a new menu item. While this may initially seem inconvenient, a good graphic design will generally not use very many different styles on any one map. The handling of text objects is pretty much as before, i.e. you have to delete back through an object to fix a spelling error, and hitting <CR> creates a whole new object. With the exception of the most common few fonts, which are assumed to be installed on all printers that you might encounter, all text is rendered in the PostScript output as a series of curves and lines - all letters are drawn out as area objects - so there's no need to worry about whether the typesetting service has the same fonts that you're using. The map that I just had the negatives made for had no explicit text in the PostScript output at all!
OCAD still also has the same dedicated PostScript output driver that we have come to know and love
Printing capabilities now include everything that Windows supports, so if you have a color (or B&W) printer, you can use it. The one special case is PostScript output. There is a PostScript driver in Windows, but OCAD 5 includes some notes explaining the various bugs that have been found in it. Therefore OCAD still also has the same dedicated PostScript output driver that we have come to know and love. This is definitely the thing to use for creating negatives, and I have also used it to create files for printing proofs on Canon CLC-500 and Tektronics printers at my local copy shop, and it works pretty well for that. The output isn't identical to what the printed map will look like (due to limitations of the printer), but it's basically sufficient for course-setting purposes. It appears that there has also been an enhancement in the way that objects are represented in the PostScript output that significantly reduces the size of the files.
The "Optimize" function does a much more thorough job than it used to, now getting rid of degenerate objects (like contours with only one point), fixing up any errors that it can, and informing you of the locations of objects of unknown type. I was going to write a utility to do all of this stuff, but OCAD 5 takes care of it.
This doesn't cover all of the capabilities of the new release of OCAD, but it at least touches on the highlights. There are numerous other things that it can do, some useful, some... well... interesting... that are out there for you to discover. OCAD has earned a reputation of being very very close to bug-free, and the new version is really no exception. (I have found a few insignificant bugs, but they're really obscure, and don't really present any problems).
Finally, the other major new features in OCAD 5, scanning and Bezier curves (which sort of go hand in hand). I haven't actually drafted a map using scanned fieldwork, but I have played around with it a little bit. For that reason, the following opinions are tentative.
OCAD 5 allows you to scan in fieldwork. Now, this does not mean that you can scan in the fieldnotes, slap on a title and a legend, and you're done. At the moment, somebody still has to draft the map. Scanning simply provides an alternative to using a digitizing tablet. What you do is to scan the fieldwork, and provide it to OCAD as a .BMP file. OCAD will then display the fieldwork as a "wallpaper background" on your screen. You can then draft by drawing things on top of this background instead of tracing them on the tablet. A caveat - you may need to fiddle around with what screen driver you're using in order to get the image to be legible. The first scanned images that I got looked like a photograph when viewed with a paint program, but came out as an illegible muddy mess in OCAD. With some assistance from Jim Baker, I installed a different screen driver (from the disk that came with my video card) that improved the situation to where it's tolerable (but far from magnificent). The scanned stuff can't be edited or manipulated in any way (other than shifting or rotating the whole image). The advantage of scanning is that everything appears on the screen, so you don't have to keep moving your eyes back and forth between the screen and the tablet (it can also save you from having to buy a tablet in the first place). As it turns out, using freehand mode to trace things on the screen doesn't work incredibly well. For this reason (among others), OCAD 5 provides Bezier curve drawing mode. In this mode, instead of tracing the curve, you click on a series of points along the curve and drag a tangent to the curve at each point. The program then creates a smooth curve between your points. If you don't like the result, you can edit the line by moving the points around, or by futzing with these other funny handles, two of which are associated with each point, that sort of steer the curve around in terms of what trajectory it takes out of each point (it makes sense when you actually see it). My first experiences with trying to draw Bezier curves were not so great - it felt like I was trying to steer a snake by holding onto its tail. With a little more practice, I've gotten a little better at it, but it still seems like it might be a rather slow way to draw things. I'll have a better idea after I draft a whole map using them (coming soon). The Bezier curves are certainly useful for some other purposes, so they are welcome, but my opinion is still up in the air about whether scanning will be worthwhile.
I can't find my pricelist, but an OCAD 5 demo disk with current prices
is available from: Hans Steinegger Software, Chriesimatt 23, CH-6340
Baar, SWITZERLAND, http://www.ocad.com