Welcome Guest. [Log In / Register]

No mariners were harmed during the production of this software

Marine navigation software, written by sailors for sailors. Ah, that sounds good. Lots of hands on, practical, real life, genuine salt encrusted sea-going experience built in. Actually I could go for a bit more on this principle. How about legal software, written by lawyers for lawyers. Not bad but you might be tempted to ask a question as to why, if the lawyers are good lawyers, they are spending time writing software. Or what about educational software, written by children for children. Now this is starting to get a bit daft. Children can’t write software. Well I am sure there are some that can but professional, well crafted, reliable software? Seems a bit unlikely and before someone tells me that their munchkin has already come up with a successor to Windows 7 my point is that is this really not a good recommendation.

The notion doesn’t map to other areas very well either. Office blocks, built by accountants for accountants. Well good luck to them. Comfy chairs, built by lazy people for lazy people. Might cause a few delivery issues. Beds, built by sick people for sick people. Unlikely to get much investment for this enterprise. So why does it sound a good idea that navigation software should be created by sailors?

I think part of the issue might be that programmers, geeks, get quite a bad press. Pale skin, thick spectacles, a propensity for pizza and a quite astounding ability to misunderstand the real world. Worse than that they just don’t speak English. I don’t mean that they are aliens but that they live in an unreal, virtual, fantasy world. They have their own language, their own humor, their own sense of reality. Naturally the software that they create, while it may be very clever, is going to be incomprehensible to a down to earth and practical mariner who is mostly concerned with the business of getting from A to B while avoiding a particularly nasty rock at C.

Bit of a conundrum. You are going to need the geeks to write good software. Just like car repairs are best left to a mechanic, fixing teeth should be left to an orthodontist and flying a jumbo jet is best when done by a pilot (trust me on this one). Creating good software is difficult and you are going to need all those years of geeky experience and training to get a professional product. It’s not like writing a book. Being an author is not easy but it doesn’t require the same level of expertise and education. In fact, as you can see here, anybody can give it a go. So sailors can, and do, write some excellent books. But software, well, that’s just a whole load trickier.

Of course there are a few programmers that also sail. These are very useful guys and behind most good navigation software you will probably find one or two of examples of this rare breed. Even so there is a still a problem. There are many right ways to sail. There are also quite a few wrong ways of doing it. I know because I have tried a few. Creating navigation software, a tool, to suit one approach can be quite challenging. Making a tool that is more generally useful is altogether a much more ambitious objective. So how do we attempt this? Well I could write a book on it. Actually, if I am honest, I would probably lose the will to live if I tried such a thing but I might consider a few blogs on the subject. If you are interested?

In the meantime we have marine navigation software written by professional software engineers (some of whom sail) guided by professional and recreational mariners which frankly doesn’t have such a good ring to it and that is possibly why nobody bothers saying it.


Displaying Soundings on a Chart

The last part of the article from Andy about soundings


There are a lot of numbers to display in a small space – even on a paper chart 40” wide.

Conventionally, soundings are displayed...


without thousands separators or units


with a single decimal digit displaced ½ a line down instead of with a decimal point (if less than about 30 feet)


with a bar under the number for drying heights, instead of using a minus sign

Units are implied by the chart – in the UK, non-metric charts were black and white and metric charts are colored. Everything is done to try and prevent someone misreading a dangerous depth for a safe one.

Sounding Units in S-57 (ENC)

ENC is one of several chart products based on the S-57 chart standard. Part of the ENC specification is that all depths and heights be specified in metric units (meters).

But the surveys in the US have been done in English units (feet). When a sounding in feet is converted to meters to be stored in the ENC format and is then converted back to feet for display, rounding errors creep in...

Original depth recorded in survey in feet

Stored in ENC in meters (to 1 decimal)

Displayed on chart in feet (to one decimal)













We could argue that 0.1’ here and there does not make the chart useless, but it does make the chart significantly more crowded with all those decimal digits. In Nuno Navigator, depths from US sourced chart data are rounded to whole feet, on the assumption that the survey was in feet in the first place.

Soundings can also be very crowded – clutter on the chart, particularly when the chart is displayed at a less detailed scale than it was intended for. The ECDIS display standard (ISO 61174) also specifies rather large text and symbols – larger than are needed on a modern LCD display. The standard S-57(ENC) presentation draws sounding values using turtle graphic symbols instead of text – symbols cannot benefit from clear-type etc.

Taking all this together the display of soundings changes from




Orignal S-57(ENC)


Nuno Navigator

At a smaller scale the difference is even more marked




Orignal S-57(ENC)


Nuno Navigator

The Nuno Navigators soundings might be a bit small to read, but the original is too crowded to read and the existence of small text is the clue you need to know that there is something there – all you have to do is zoom in a bit to read it. Everything else about the chart remains intelligible – you can still see the contours clearly for instance.

Highlighting Soundings

The “Properties at Point” display is an important element of an ENC chart. It shows all the detail of the last thing you clicked on and is one of the big advantages of a vector chart.

It is important to know what you actually clicked on.


We highlight this on the chart.

Here, I clicked on a buoy.


But it didn’t work so well for soundings, which by a quirk of the S-57 design are grouped together.

Here I clicked on the 11.5m sounding lop left.


But, by remembering the depth of the sounding that was actually clicked on, we can now make it work much better

What Soundings Mean

More from Andy about soundings…

The traditional lead line sounding made point measurements. The cartographer positioned them on the chart and interpolated between them by eye to draw depth contours. Cartographer and navigator alike had to assume that the gaps between the soundings were not a significantly different depth from the soundings themselves.

A worried cartographer could possibly order the surveyor to take more soundings but there would always be gaps and assumptions.

Modern sounding techniques are fundamentally different – side scan sonar imaging is effectively continuous – there are no gaps. No rocks will be missed. This can give the navigator a much higher degree of confidence than from point soundings. The soundings drawn on the chart can be positioned at the shallow bits such as isolated rocks.

So on a chart produced from a modern survey, the soundings are worst case, whereas from a traditional survey they are probably average and the spread of depth may be quite uncertain.

(caveat. Where it was particularly important to know there was a safe depth, traditional soundings were bolstered by using a drag line – if nothing caught on the line, which was set at a fixed depth with floats, then the area was entirely deeper than that.)

The source Data Diagram (SDD) on a chart tells us which type of survey was used:


A typical SDD from a BSB NOAA chart showing areas of full bottom coverage (modern survey techniques) and partial coverage (traditional survey techniques)


An SDD from Nuno Navigator, showing the S-57 equivalent (though for a different location). A2 is a full bottom coverage survey and U is ‘unknown but probably not’.


The Source Data Diagram for the chart containing the single line of soundings (above) contains the tracks of the individual ships that contributed soundings to the chart.

“Easy to use”. What does that REALLY mean?

When we started writing Nuno, we really wanted to make it simple and easy to use. That's easy to say — but not as easy to do.

Most of the software products we write at CherSoft are large systems. These products are used every day by trained professionals, who can afford to spend a week learning how to use the product, if it means they can do their job much more efficiently later. For Nuno, we've been trying hard to adjust our mindset. Our customers are mostly not trained professional navigators, they won't be using the software every day, and we hope they are more interested in enjoying a weekend away on their boat than they are in fiddling with navigation software.

For Nuno, we think “easy to use” means

  • People should be able to put the software onto their computer easily to try it out.
  • People should be able to see quickly whether Nuno suits their needs
  • People should be able to learn how to use Nuno even if they are not confident with computers. They shouldn't need to read manuals or search online.
  • People shouldn't be able to break anything or get confused about what they have done with it
  • The Nuno experience should be all about sailing a boat or planning a trip, not about struggling with software

As we started out, we had a really clear idea of what we don't like in the software we use in our daily lives. We don't like menus. We don't like dialog boxes. We don't like having to remember where things are or what they do. We don't like enormous seas of confusing options and settings.

As we went along, we quickly discovered that it's not easy to write simple software. Now we've finished, I think we've done a reasonable job of it, and I've put together this list of the principles we leaned on to guide us.

Ubiquitous direct manipulation

If I don't like something, I want to be able to grab it and change it. I don't want to go hunting in a menu for an option.

In Nuno Navigator, to change the chart orientation you grab the North arrow and drag it round.

Minimal mouse mileage

Once I'm familiar with a particular program, hiking my mouse around just slows me down. If I have to refocus my attention constantly and move my mouse away from what I'm working on, I'm likely to keep forgetting what I was trying to do in the first place.

The “ubiquitous direct manipulation” I mentioned earlier is good for maintaining focus. If I decide I want to change the name of a point, my mouse is probably near the point name already, so it's easy to mouse to the point name and edit it there on the chart.


I'm also a big fan of “Context Menus”, where each item has its own mini menu. If I've drawn a point overlay on the chart, and I want to change the symbol shown on the chart, I click on the point with my right mouse button and select a new symbol from the list. I don't have to move my mouse far and I don't have to wade through lots of menus filled with irrelevant options. The only options in the menu are the ones that make sense for a point — that's why it's called a context menu!


Everything is reversible

Right from the beginning we knew we needed good support for Undoing things. We want everyone to be able to play about with Nuno in the confidence that whatever they do, if it doesn't work they can just hit Undo straight away.

Like newer versions of Microsoft Office, our Undo / Redo menus give you a drop down list showing what you've done, so it's easy to understand what you did and what you are undoing.

Be helpful

We use "hover tips" to show you how you can interact with something.


Don't make people feel stupid

Have you ever gone to make something special for dinner, and discovered you don't have the right ingredients? Or come back from the hardware store with a new drill, only to find out you don't have any drill bits? Have you ever typed your credit card number into a website, only to be told you are wrong, and credit card numbers can't have spaces in? Did you forget where you saved a document?

One of the reasons I like working in software is that we can often fix problems like these. Some of the time we can just fix the problem automatically and you'll never know about it. For example, if we need your credit card number without spaces in it, we can just make the software remove the spaces. When we want to talk to your GPS we auto-configure it by ourselves instead of asking you to tell us the settings. Some of the time we need some help from you, but usually we can just ask you a couple of questions and then let you get straight back to what you were doing. We try not to stop you and put up a big sign saying “No! Wrong!”.

The results

We're fairly pleased with how Nuno turned out, but we're sure we could make things better. What do you think? Do you find Nuno easy to use? Has Nuno ever left you feeling stupid or wondering what happened? Let us know about your experiences in the comments.

Updating charts is a bit of a mess

Globally the whole business of updating charts is in a bit of a mess at the moment and probably will be for a while. Most national hydrographic offices are fairly well set up for maintaining their paper portfolios. This is no great surprise as some of them have been in this business for a century or more. However with the advent of electronic charts a lot of things have to change. The whole production process needs to be reorganized (not cheap) and some of the basic ways of thinking about charts have to change.

Raster charts are commonly produced as facsimiles of the paper charts. In a simplistic system they are literally scanned from the paper originals. This can give rise to inaccuracies for a range of reasons not least of which are distortions in the paper and non-linearity in the scanner. Scanning at a resolution appropriate to the electronic chart can cause a rather jagged appearance which is most noticeable in diagonal lines and known as aliasing. The raster chart has far fewer dots (pixels) than the corresponding paper chart and this can compromise appearance. A better production method is to create the raster image from the same electronic chart images used to drive the paper printing process. There are still some issues here with re-projection which need to be handled correctly but in general this is a cleaner and more accurate process. It also allows image processing such as anti-aliasing which gives a better visual impression when the electronic chart is displayed.

In either production technique the updating of the raster charts follows on more or less naturally from the time served paper chart update process. It is then common for the vector charts to be produced from the raster data, more or less indirectly from the paper chart production mechanism. At the end of the update chain are the third party chart producers who copy the official data sets and repackage them in a variety of ways. Quite naturally these are the last types of charts to get updated.

But this is all changing because this is not a good way to handle vector data and vector data is the future. It is a separate issue as to why vector charts are the future or whether it is the right future but for now it definitely is the future. The IHO and other august bodies are committed to this and substantial funds are being invested. This matters because creating vector data from paper charts is just not a good way of doing things.

In the vector world everything is an ‘object’ like a light or a depth contour or a traffic lane. Each object has ‘attributes’ like the color red or a certain depth. Each object also has a position (the ‘vector’) so it is represented as a point, a line or an area. These objects can be quite readily managed in a simple database but the natural way of organizing them is to tie them more directly to the raw survey data. So when a report is received that a new wreck has been found it is just entered into the database – no intervening chart required.

Vector charts are now a cinch to produce. A cell is just a collection of all the objects in a given geographical area. The problem of actually displaying the chart data is palmed off to the ECDIS or ECS. Paper charts and raster charts are a bit more problematical because the traditional role of the cartographer has been taken out of the loop. Have you ever wondered why a modern chart display simply just does not look as good as a paper chart? Well this is why, there is no longer a cartographer involved to lay out the chart and make it look ‘just so’. Instead we have a dumb computer, and they are all dumb, attempting to reproduce the sort of work that takes a human many years of training and experience. It just doesn’t work so well.

Now to be fair the automated vector to raster production processes are getting better but none the less there is still a complete role reversal. The raster chart becomes a second class citizen to the vector chart and the paper chart ends up at the bottom of the pile. Instead of being the primary focus for updates it becomes the last. There are undoubtedly many advantages with vector charts and with paper charts generated from vector databases. However, for the foreseeable future, they are never going to match the visual quality of the charts that have become standard fare for the mariner for many years.

Last in the chain will always be the third party chart producers. Fortunately as their update feeds become predominantly more electronic (just another output from the database) then these updates should become more timely. Ultimately they should be able to match the official charts for accuracy.

Just now we are in a great transition phase. Some hydrographic offices are pushing ahead with vector only systems while others just deal with traditional paper charts. Most are somewhere in between and possibly a bit unsure of which way to go or how it is all going to shake out. Meanwhile the mariners can look forward to improved electronic charts coverage and more rapid updating. They can also anticipate charts which do not look so good and which, in some cases, are going to cost more. Maybe this is just a classic engineering compromise.



Today’s blog is the first of a short series from Andy Watkin. When not writing code Andy is often to be found poring over charts. Lately he has been thinking about soundings…


In the beginning, someone stuck an oar over the side of their boat and found that the water was deep enough at that single point for their rowing boat. Now we can measure the depth of a whole area simply by flying a small (suitably equipped) airplane over it and display all these depths on a screen.

As part of the development of the chart display for Nuno™ Navigator, I looked at the way soundings have evolved.


A single line of soundings indicates measurements made during a voyage – rather than a dedicated survey where the ship passed back and forth over the area. This was common in Captain Cook’s time and is still obvious on some current charts.

As each sounding was measured manually with a lead and line there are only a few and they fit easily onto the chart. A lead was a substantial weight: www.nmm.ac.uk. Great skill was required to throw it forward so that by the time it hit the bottom the line was vertical (thus allowing for the forward movement of the ship). At the depths above, they probably had to heave to each time.

The depths were marked on the line using bits of leather, bunting, etc, as shown in www.navyandmarine.org. Of course, on old sailing ships, the line had to be readable in the dark as well as in daylight – so each of the mark had a unique feel. Taking soundings from the deck of a heaving ship in the dark in a gale (with little idea where you really were) must have been a terrible job.

There is a whole language around the use of the lead and line, complicated by not marking all the depths.

· “By the mark ten” is 10 fathoms (60 feet).

· “By the deep eleven” is one fathom deeper than the 10 fathom mark. A fathom is of course approximately the distance between outstretched finger tips, which was presumably used to estimate the intervening lengths.

clip_image004 The lead line was not just used for measuring the depth. When the only positioning devices were a sextant and a sharp pair of eyes, finding out what the sea bed was made of could be a vital clue to your position. A hollow in the end of the lead was filled with tallow (which is sticky) and would bring up a bottom sample if you were lucky. This is why charts are marked with “mud”, “shingle”, “sand” etc.

Modern Soundings

Rather than measuring one depth at a time with a piece of string, a ship can use a side scan sonar to build an image of the sea bed for a significant width either side of the ship, all the while steaming along. The sensor can be built into the hull of the ship or towed in a ‘fish’ – a floating torpedo shaped housing. A fish can be controlled (it has underwater wings) to stay at a constant depth providing the ship’s speed is maintained constant. An advantage of using a fish is that, being entirely under water, it is not subject the pitch, roll and yaw experienced by a ship.

The sonar images can be remarkably detailed. www.abc.se contains some good examples.

The most amazing technique though is LiDAR - the word is a composite of light and radar. Two lasers are shone downwards and swept from side to side from an aircraft. One is a frequency (color) designed to be reflected from the sea surface. The other is a frequency designed to penetrate the sea and be reflected by the sea bed. Comparing the two, with a lot of computer processing allows the depth over the entire width of the scan to be determined – and the aircraft is moving forward at a rate so huge areas can be covered by repeating the process quickly enough. The depth that can be measured is limited by the sea opacity and does best in shallow areas; which is ok as that is where we generally care about most.

Choosing a tag line

Choosing a tag line

A tag line is that little piece of text associated with a product and much loved by the marketing people. ‘Just do it’, ‘Where’s the beef?’, ‘Think different’. That type of thing. Catchy brief phrases that sort of make you feel good and, hopefully, remind you of the product.

So at the Nuno philosophers meeting it was generally agreed that we should have a tag line. Why not? Everyone else seemed to have one. That was the easy bit. Next problem, where to get a tagline from? I thought that maybe I could get the ball rolling and suggested ‘really good navigation software’. This seemed, to me, quite clear and to the point but everyone else laughed and said it was rubbish. None the less, even from this naïve attempt we learnt some important things:

· Thinking up a tag line can be difficult

· Thinking up a good tag line is harder

· If you are going to think up tag lines and share them with your colleagues then you need to be quite thick skinned

Next attempt was to throw the net a bit wider and see if any of the developers could dream up anything. We stoked them with extra pizza and coffee and they came back with ‘notepad of the seas’. This is quite a nice idea but needs some explanation for non-programmers. Notepad is a small text editor which has been shipped with Windows since forever. It just does one job; editing plain text. The thing is that it does this job really well, it is always there, it is reliable, it is predictable and it is easy to use. I doubt there is a sys admin or coder alive who has not used it sometime to modify a configuration and save the IT infrastructure. There are some people that even use it to write code, although this is generally considered a bit hard core. So, nice identification but too much of an explanation for a tag line.

Doing some background research I came across some useful pointers such as

· Keep it believable, succinct and interesting

· Make it thought provoking, unique and memorable

Which is all very well, but how? I also found an automated tag line generator but this mostly just seemed to quote Star Trek and I did not think ‘beam me up Nuno’ was going to cut it.

We needed to get everyone on the job, management, testers, coders, interns, even the janitor. Then things began to buzz. We started with ‘nav and go’. Then there was ‘show me the way home’, ‘software like mom used to make’, ‘be where you want to be’ and ‘you know Nuno knows’. Everyone was getting into the swing of this now, especially when we offered a bottle of wine for the best one. ‘ocean knowledge’ is one we might use for CherSoft. There was a rather blunt suggestion of ‘just buy the f**g thing’ which was tempting but inappropriate. Other little gems included the song inspired ‘it’s a greater navigator’ and ‘smooth navigator’. There were also little puns like ‘it’s all a plot’ and ‘useful in a fix’. My favorites included ‘life is too short for getting lost’, ‘navigator in a box’ and ‘just add water’.

Having got to over 50 candidate tag lines we thought we’d better put it to a vote. This proved interesting because there was no clear consensus at all. It would seem that the notion of what makes a good tag line is very subjective. In the end, through the use of a slightly implausible transferable vote system we arrived at ‘it’s all on the chart’. This has the comfortable feel of time served salt encrusted wisdom and a slightly subtle double meaning. With Nuno we try and make all the user interactions directly on the chart. There are no dialogs or status panels instead everything is, as far as possible, right there on the chart.

So there we have it, ‘it’s all on the chart’. Will this herald a new age in the development of Nuno? I doubt it but it was kind of fun.



choosing the right choices

Choice is not necessarily a good thing although it can superficially seem positive. “Would you like a choice?”, “Oh yes please”. Without quality or real purpose behind the choice it can easily become just so much noise. There is a lot to be said for choosing a restaurant with a short menu. They will tend to concentrate on getting these few dishes just right. If you are lucky the food will even be freshly prepared. An extensive menu on the other hand might indicate a lot of freezer space and a bank of microwave ovens.

When we are designing software it is all too easy to implement too much choice. There is a constant stream of decisions ranging from the aesthetics of how to lay out a dialog to parameters that control data flow and the underlying program operation. Often it is tempting, easier, to defer these to the user. With layout decisions the programmer can completely duck issues such as creating a balanced look. What color should this line be? I don’t know so I’ll let the user decide. In one sense this is more work, certainly there is more code to written. But this is easy stuff for a programmer, it is what they do and this can be a more appealing path than stepping outside of the comfort zone and taking an external perspective. Adding more user choice may seem like empowering the user. Sometimes this is true but not always. It is always bad to clutter up the user interface because this will detract from the real purpose of the application. There is always the risk of a combinatorial explosion of optional parameters leading to many that simply don’t work. The control bar gets moved off the screen or the text becomes invisible or an unanticipated configuration simply causes the program to crash. In earlier versions of Windows it was perfectly possible to set the color scheme to something completely unusable, to make the task bar vanish, to stop the mouse dead in its tracks and to get the keyboard to generate gibberish. Actually some of this may still be possible but I have learnt to stop fiddling.

Some user options are essential – but which? One guideline is to think about what the application is trying to achieve. An accounts program would probably be equally useful if it had a grey border or a blue one. It doesn’t matter too much. On the other hand a fashion conscious teenager might consider the skin color of their iPhone application to be a fundamental expression of their personality. Often it seems to me one of the many by-products of age is a preference for things that ‘just work’ over trendier considerations, but that is not the point here. The point is ‘can the program work just as well without this option?’ because if it can then maybe the choice is just clutter.

To me the worst choices are those I don’t understand. ‘What allocation size to use for the secondary backup cache?’. I don’t know. I don’t even know what color the cache should be so now this software is starting to make me feel stupid. Configuring a network connection used to be a minefield of difficult questions like this. Fortunately, after possibly diverting some funds from the helpdesk to the development team, this has now become mostly automatic. It just works. That’s  much better. If the program can work it out for itself then it should. Even, and this can often seem the case, if it involves loads of code to do something that the programmer thinks should be ‘obvious’ to any half informed user.

Another good way to spot the better restaurant is by how crowded it is. Confident and keen to impress, I once led the way into a very promising and packed Parisian eatery only to find that the sole occupants were in fact a visiting rugby club and their supporters. We chose to leave shortly before the first course but just after the singing started.


The Nuno Navigator Blog

My company, CherSoft, has just launched a new product called Nuno Navigator. This is a whole new direction for us. Sure we have written lots of marine software before but this time it is different, this time we are trying to sell directly to our end users. Previously, by which I mean the last 15 years, we have mostly just operated business to business. We wrote the software and someone else would sell it. Sometimes they would use their own badge and branding and sell it as their own. This is quite normal, much of the software you use is not written by the company on the box. One particular company even attended a lavish ceremony and dinner to accept an industry award for our software. We only found out about this much later.

Working as a back office company has quite suited us for quite a while. It meant that we could get on with writing software which is what we like best. It meant that we didn’t have to get too involved with things like sales and marketing which was fine too because we didn’t really like that too much anyhow. Of course there was a down side. We spent a fair bit of time worrying about contracts and specifications. We spent far too much time quibbling about how to write the software or what it should do or what it should look like. So all the time there has been that temptation to strike out on our own and actually create a software application start to finish that we can call our own.

Anyhow, we’ve decided to step out of the shadows and face the harsh and unforgiving glare of end users directly. This is a bit daunting but hopefully we are not completely unprepared. The code is pretty solid, we know a fair bit about marine navigation and we have cobbled together a website. Well ok, I know there is a bit more to it and that is what this blog is about. I’d love to say it will be a ‘how to’ on launching a new software product or a better navigation system but the reality is that we’ve still got a lot to learn and a lot to find out. So instead it is going to be ‘stuff’ with a vague theme of things associated with software and navigation. I guess it is also going to be about facing the great and wonderful public directly and probably about some of the things that happen to us along the way.