Charts are square, countries aren’t, it’s a problem. There may be a vision of a utopian world where country boundaries are straight and align with a geodetic grid but the reality, as usual, is much messier. The tricky bit is that each national hydrographic office will create ENC cells with bits missing. The political ramifications of drawing a map of someone else's country can be severe. Politicians just don’t like this sort of thing and Google have managed to upset people to a remarkable degree by misplacing the odd line. So the only sensible thing to do is to create chart up to the national boundary and then stop. Of course by safe I mean politically safe. For the mariner it is a pain in the transom akin to sailing off the edge of the world.

This means we end up with multiple ENC cells of the same area at the same compilation scale but from different providers. The reason you might care about this is that you could easily end up with duplicate or similar features from both cells overlaid on each other. Depending on how your chart display software renders this it will probably look a mess, could easily be confusing and might even be dangerous.

Fortunately the good people at the International Hydrographic Office have already thought of a solution to this. Unfortunately it requires a degree of international cooperation and we (I am speaking for the whole human race now) are not very good at that. None the less several countries have been giving it a go following the principles of the Worldwide Electronic Navigational Database or WEND. This is a great idea and would be even better if it worked. I am not saying it won’t work but there is a way to go yet. One small step in the right direction has just been announced by NOAA and the Canadian Hydrographic Service. They have conceded that the boundary between the US and Canada is not straight so they have agreed on using a wrinkly one instead.

ENC cells are often cataloged and managed by the coordinates of the cell corners. This is fine most of the time and implies that the cell is square. However within the cell is a coverage object which really defines the shape of the area covered by the cell data. This can be a polygon of as much complexity as needed. So if two countries cooperate they can arrange the coverage boundaries along the international border, each country then charts its own bit and everyone is happy. The UK and France are a good example of where this works well. What is happening up on the Canadian border seems to be a little different though. They are still dividing up who does what but, see the above diagram, they are not following the border. Instead they are making sure the the cells will fit together properly but Canada is charting some of the US and visa versa. Why are they doing it this way? I have no idea. Please tell me if you can shed any light on this. Pragmatically the reason does not matter too much. The end effect will (should) be a set of ENC cells which join up nicely.

There is a lot of talk about ECDIS training at the moment. In the next few years ECDIS will become mandatory for quite a wide range of commercial vessels. Clearly having this kit on board is of little use if nobody knows how to use it and so the requirement for training is becoming prominent.

The argument assumes that the ECDIS cannot be used adequately without appropriate training. This is probably not a bad assumption because the usability of commercial ECDIS software tends to range from difficult to verging on impossible. This may surprise you. Expensive software doing an important job on what may be a large and very expensive vessel. Surely it should be designed to be easy and straight forward to use? Oddly enough this is often not the case. There are several reasons for this:

· The standards, specifically ISO61174, does not lend itself to useable software. This is the performance specification for ECDIS. It is over ten years old and is very detailed. Naturally it is based on ideas and technologies that were prevalent ten years ago. Ten years is a very long time in the computer world – we are talking pre-Windows 2000. What is more at the time the standard was written there was not much around in terms of marine navigation systems and chart data. So rather than drawing on best practices and experience the standard needed to present a vision of how the committee thought that navigation software was supposed to be. Now I don’t actually know how the committee was chosen but I would guess that there were very few computer usability experts amongst the members. Even if there were then they were faced with an impossible job no matter how good their crystal ball was.

· So designing ECDIS compliant software that is also usable is difficult in the first place but it gets worse. Given a realistic situation of limited budgets and resources the focus of the development effort tends towards compliancy issues. Usability is a secondary issue since unless the ECDIS can be certified as compliant with the standards it cannot be sold as an ECDIS.

· Actually getting the software certified is a time consuming and expensive business. I am talking many months and thousands of dollars here. It is not trivial. Once the software is certified then it cannot really be changed without being re-certified. This situation does not lend itself to the sort of on-going development necessary to make genuinely user friendly software. In fact it does not lend itself to any sort of development at all. One of the more popular ECDIS systems around at the moment is actually based on Windows NT4. Remember that? Yes, an improvement over NT3.51 but still a tad short of sparkling when it comes to usability considerations.

· Ship owners are a tight fisted bunch. They typically they will not spend a penny more than necessary on equipment so as long as it meets the regulations. At which point it is usually the cheapest system will do. I am not saying this is wrong, running a ship is a fantastically expensive business, but it does tend to make for comparisons based on simple cost rather than other factors. A particular company’s software may be easier to use but if it is more expensive than its rivals then it will be hard to sell.

Hopefully you are getting the picture now. In an attempt to make ECDIS ‘correct’ and sufficiently similar between all implementations the international regulatory bodies have completely shot themselves in the foot. They have created an environment where the bulk of the development effort and costs are aimed purely at achieving ECDIS compliance and all other considerations fall by the wayside.

S-100 is the chart data standard intended to replace S-57 at some point in the future. The groups working on this have recognized that a typical ECDIS can be a bit tricky to use. They have also noted that each ECDIS tends to be tricky in a different way so they have come up with a solution called ‘S Mode’. The basic idea is that every ECDIS has a button which will set it into S Mode. In this mode the controls, menu options, settings and so on will be exactly the same irrespective of which company made the ECDIS. This is such a beautifully naïve notion. It says ‘we’re a bit scared of this software so let’s make it all the same’. Of course any company developing ECDIS will implement S Mode and probably stop there. Where is the incentive and budget to do anything more? Where is the competitive edge? It all boils down to cost, how else do you differentiate systems that all look and feel the same? And so we arrive at a dead end which ensures training will always be required.

There is only one way to make software more usable and that it to allow software developers to experiment. They have to try out ideas and find out what works. It is very difficult. In fact it is amazingly difficult but we are making progress. There is still ample scope for improvement but at the same time I feel no need at all for a training course in how to use my iPhone. I doubt that many of the millions of iPhone users do. By comparison my last car, which was a few years old, had an early mobile phone in it (this is back in the days when ‘mobile’ actually meant ‘semi-portable’) and no, I could not actually make the first phone call without consulting the manual. That phone and the ECDIS performance standards come from the same era.

Nuno does not come with any training courses. This is not a declaration of irresponsibility but because we don’t think it needs one. It is not technically an ECDIS but it will do pretty much anything that an ECDIS can do and in most cases it will do it a lot better.

Many paper charts include a Source Data Diagram (SDD). This is small inset displaying the charted area which indicates something about the origins of the information used to compile the chart. There can be some important stuff here.

This SDD shows that some of the soundings come from a lead line survey in 1832. In other words... and think about this carefully ... a hundred and eighty years ago somebody stood on deck with length of hemp rope with knots or marks on it and a heavy weight at the end. From the numbers he shouted out you are going to decide if there is enough water to avoid grounding your boat. To be fair most commonly used waterways are much more recently (and accurately) surveyed than this but even so it can be worth checking. The chart may be completely up to date but the original survey could have been a long time ago.

Of course with your shiny electronic charting system you may think that this sort of consideration is not an issue any more. Sadly this is not true. Most electronic charts are created from paper charts and this will probably be the case for a while. Now clearly the underlying accuracy of the survey data is a concern. The designers of S57 had a think about this and came up with the notion of a ‘Category of zone of confidence in data’. This is chart meta-data - data about the data. Areas are defined and for each area the quality of the underlying survey data, the Zone of Confidence (ZOC) is classified as one of:

This looks quite promising. Instead of telling me something about where the data came from they are going to tell me directly just how accurate it is.

These meta data objects are designed to be used at the compilation scale of the chart however this does not seem quite right to us. The information is really part of an overview of the chart, a summary, so in Nuno we are introducing an overview window. This displays the Zone of Confidence areas and has some other nice uses too.

A second potentially useful bit of information for the overview comes from 'Nautical publication information' objects. This is more meta data which is a reference to a specific paragraph from a nautical publication. Quite usefully this is often a note about the paper chart which was used to create the electronic cell and in particular the source date of the paper chart.

So in Nuno we have put this information together into a nice little inset window which can be easily displayed or dismissed. It gives you a handy overview of the main chart view and its surrounding area. It also supports panning and zooming which can be a neat way to move the view around larger areas. 

You can click on the little button I have circled in red to make the overview disappear. Technically this is called an affordance (just in case you wanted to know).

Sad to say there is small hiccup in this scheme and this is because of another value for Zone of Confidence which does not appear in the table above. The value is U and this means ‘data not assessed’. Which is to say that the creators of the electronic chart cells have chosen not to specify anything about the quality of the chart data. To my mind it is a bit unfortunate that this value even exists however it gets worse because for the most part all the NOAA data is classified as U. A few newer cells use B but most of them are just U.

I was recently at an IHO meeting to discuss S-100 which is the chart standard currently being designed to replace S-57. One topic was a consideration of ways to display the S-100 equivalent of this sort of data quality value. There was, as usual, much discussion on this, but to my amusement nobody pointed out that unless the chart producers actually encode this information then it does not really matter how it should be displayed. S-100 is a long way off but for now, please NOAA, could you start adding more zone of confidence information? It is really quite important information. The Nuno overview is useful in its own right and it displays the date of the source chart for each area. It also displays the data confidence level so if more of this were actually in the cells then we would really have an electronic equivalent of an SDD. Come on NOAA – we are all ready for you.

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.