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.

The last post dealt with loose cells. Now we are going to consider Exchange Sets and finally Transmittals.

The Navigation software needs to import cells and updates. The result of this is stored in some kind of SENC. That is a System Electronic Navigation Chart (Google for SENC and you’ll find many definitions other than this one but just bear with me). The thing is that while a single .000 file can be displayed directly the cell update files need to be applied to the corresponding base file first. They also need to be applied in order. The SENC then is the result of installing base files, update files and possibly other files. The SENC is what your navigation system reads to display charts. An Exchange Set is the standards definition of the set of files that can be applied to a SENC.

The ENC product specification states that an exchange set contains a catalog file, one or more data files maybe a readme file and possibly some text and picture files. These last two are referred to as auxiliary files and contain information which is supplementary to the cells. That is, an object in a cell may refer to one or more auxiliary files to provide addition information.

The catalog file contains an entry for every other file in the exchange set. It describes where the file is in the exchange set (different organizations may use different folder structures) and also some checksums to ensure that none of the files are damaged. Bearing in mind the previous discussion about updating cells you might also hope that it contained the edition and update number of the cell files in the exchange set but sadly this is not the case. Some organizations put this information in a comment field but since this is not mandated it is not reliably present. So you can have update logic that uses the edition and update numbers from the catalog but it also needs to be able to fall back to reading this information from the cells themselves – which is perfectly possible but takes longer.

The standard describes how the volume label of the exchange set should be made up. If you are not savvy about volume labels then no matter because nobody really takes much notice of this. In principle an exchange set could be split across several volumes but I don’t think this ever happens. In the volume is a folder called ENC_ROOT which contains the catalog. The cell files may be in this folder or are commonly placed in sub-folders. A directory listing might look like this:

Does that bring back memories of those heady DOS days c:\ > ?

So the basic update algorithm is to locate ENC_ROOT\CATALOG.031, read it and then install all the files it mentions. Overall the mechanism is a bit clunky and can lead to some seriously cryptic error messages. It can be made to work but there are corners which have not been thought out very well. Management of the auxiliary files is one example of this. In fact some of the omissions are possibly evidence that the standard preceded any real implementation.

A Transmittal is a super set of an Exchange Set. Each producer of data tends to have their own take on the standard and often include additional files. This is allowed by the standard. The trouble is that if any software relies on the additional data then it can only be used with data from that supplier. This is a pity because some of the additional information can be quite useful. There is often a complete catalog of what is available (albeit just from that producer) and other information. Check for a folder called \INFO or the such.

The standard actually prohibits the use of compression (S57 Appendix B1 5.2 if you care) which seems a bit unfair. NOAA go ahead and compress it anyhow so when you download charts from http://www.nauticalcharts.noaa.gov/ they will arrive in a zip file. Decompress this and you will find the transmittal contains an exchange set pretty much as above. Each cell has its own folder which contains the base cell and sometimes quite a lot of updates. The readme file contains a catalog which is not in the most readable form but can still be quite useful.

The catalog information in a transmittal can make for a useful geographical display.

S-57 data is transmitted from place to place is a variety of formats. This can be a tad confusing. It confuses me at times and it confuses my dog. This article is an attempt to cast some illumination on the subject.

To begin with we need to be fairly precise about terms. Specifically we are not simply dealing with S-57 but the ENC (Electronic Navigational Chart) product specification. S-57 describes a fairly generic mechanism for exchanging geographic data. ENC is a specialization of S-57; a product. This describes a sub-set of all that might be possible with the broader S-57 and ties it down to some specifics. Eventually we get to a list of allowed entities, how they relate to each other and how they get updated.

The world is divided into cells. Cells are regular and rectangular. They are not the same as charts. A chart typically is designed for a particular purpose and is the right shape and coverage for that purpose. Cells on the other hand are designed to give a complete tiling so often several cells are required to give the same coverage as a particular chart. Cells come in six different flavors called Navigational Purpose which roughly correspond to scales.

1	Overview	covers the most area
2	General
3	Coastal
4	Approach
5	Harbour
6	Berthing	most detailed sort of cell

I use the word ‘roughly’ because there is no real consistency between producing agencies as to how the differences between Navigational Purpose are managed. In general the more detailed Navigational Purposes use a smaller compilation scale and so correspond to larger scale charts.

For each sort of cell there are two types of file that we are initially interested in: a base cell file and an update file. The base file is the first type of file that is ever issued for a cell and contains the all the basic chart data. Update files are produced later and contain incremental updates. That is they contain only the information needed to update a cell from its current version to the next version. So it is essential that updates are applied in order. This is what the Update Number is for.

The name of a cell file is made up like this:

CCPXXXXX.EEE

| | | |

| | | |----- EEE = update number

| | |-------------- XXXXX = individual cell code

| |------------------- P = navigational purpose

|----------------------- CC = producer code

So, for cell EC09M which is Chesapeake Bay from a compilation scale of 1:200,000 (navigational purpose Coastal) produced by NOAA :-

· US3EC09M. 000 is the base cell.

· US3EC09M. 001 is the first update to the base cell.

· US3EC09M. 002 is the second update

· And so on…

Unfortunately this reasonably simple scheme is not the end of the story. Occasionally the producer of the cell will roll all the updates to date into a re-issued base cell. In this case the cell will be published as a base cell (.000) but the update number will not be zero. So the publication sequence might look like this:

File Name	Update Number
US3EC09M. 000	0	base cell
US3EC09M. 001	1	1st update to the base cell
US3EC09M. 002	2	2nd update to the base cell
US3EC09M. 000	2	re-issued base cell which include updates #1 and #2
US3EC09M. 003	3	1st update to the re-issued base cell and also the 3rd update to the original base cell
US3EC09M. 004	4	2nd update to the re-issued base cell and also the 4th update to the original base cell

So how do you tell the real update number from a .000 cell? Well fortunately it is usually possible to read this information from the cell. So encoding the update number in the file extension is interesting but stops short of actually being useful because you may well have to read the update number from the file anyhow.

We are still not done though.

Occasionally the cell producer will create a whole new edition of the cell. This is comparable to a new edition of a paper chart. In this case a new base cell is created and the update number also gets reset because subsequent updates will apply to the new edition base cell and not the old one. In fact it would be and error to attempt to apply an update for a new edition to a cell of the previous edition. This means we also need to track edition number which is not part of the filename at all but can be read from the cell. Here is the complete publication sequence:

File Name	Edition Number	Update Number
US3EC09M. 000	1	0	1st edition base cell
US3EC09M. 001	1	1	1st update to the base cell
US3EC09M. 002	1	2	2nd update to the base cell
US3EC09M. 000	1	2	re-issued base cell which include updates #1 and #2
US3EC09M. 003	1	3	1st update to the re-issued base cell and also the 3rd update to the original base cell
US3EC09M. 004	1	4	2nd update to the re-issued base cell and also the 4th update to the original base cell
US3EC09M. 000	2	0	2nd edition base cell
US3EC09M. 001	2	1	1st update to the 2nd edition base cell
US3EC09M. 002	2	2	2nd update to the 2nd edition base cell

Confused yet? There is more to come but this is probably the worst of it. To recap:

· A file name ending .000 is a base cell containing a complete set of chart data which can be displayed. We refer to these files as loose cells and it is the way that several agencies distribute their chart data. You need code to actually read the edition number and update number from the cell.

· A file name ending .001 to .999 is an update to a base cell. This does not contain information that can be displayed directly; the update always needs to be applied to a base cell first. The correct base cell will have the same file name but with a .000 extension. Unfortunately several of these may have been issued and the update will only apply to one of them.

In Nuno we display the combined edition and update number as a single decimal number. So for example 2.003 is edition 2 update 3 and 11.589 is edition 11 update 589. This is quite a convenient representation because it allows rapid comparison of both edition and update numbers in an easy and familiar way:- 3.004 is more up to date than 2.845.

Ok that’s loose cells pretty much dealt with but this is not how S57 data is supposed to be distributed. Next time we’ll look at Transmittals and Exchange Sets.

Commercial shipping has a requirement to carry up to date official charts. Traditionally these have been paper charts. Every few weeks a chart agent will visit the vessel bringing new charts and also updating the charts on board. Updating consists of adding pencil annotations, overlaying bits of tracing paper and even pasting on a small, new pieces of chart. This is all tedious and time consuming so it is easy to see the appeal of digital charts and automated updating. However commercial vessels cannot simply switch over the digital charts. The official part of the requirement is important.

After quite a lot of wrangling and discussion between the International Hydrographic Office (IHO), other international ship controlling bodies, various national Hydrographic Offices, chart producers, equipment manufacturers and an assortment of other interested parties some standards emerged. S-57 was designed as a standard for transferring data between hydrographic offices but it got co-opted for sending charts to ships using a product specification called ENC. There are some other S-57 products such as AMLs and AIO but these came later. S-63 was designed as the license enforcement and encryption layer. Unfortunately this was published with errors in it which are still propagating issues today. S-52 was an attempt to decouple the presentation (symbol) for an object from the data representation. This started quite well but then got terribly complicated so that now S-52 is almost like a small programming language in itself. In consideration of the overall system requirements ISO61174 was produced. This describes equipment and software performance standards and is the main standard against which equipment is tested. A navigation system, hardware and software, which complies with all these standards is known as an ECDIS (Electronic Chart Display and Information System). An ECDIS can be used , with some qualifications, on a commercial vessel to satisfy the chart requirement.

Unfortunately the ECDIS standards are quite old. S-57 was frozen in 1996 and ISO61174 dates from 1997. Now old, as such, is not necessarily a bad thing, but these standards prescribe the behavior and performance of computer equipment which had not even been invented at the time. They are standards based on a prediction of what the future would be like. As such they are not a bad guess but are still well short of the mark when it comes to contemporary approaches towards interacting with computers. Nuno Navigator is not an ECDIS. At CherSoft we have developed software for ECDIS. In fact we have quite a long history of this. However in Nuno Navigator we have taken the best features of ECDIS, the bits that actually work, and brought them into a thoroughly modern and genuinely user friendly environment. Nuno Navigator is classified as an ECS (Electronic Charting System) rather than an ECDIS. It is not really intended for commercial vessels.

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)
3	0.9	3.0
6	1.8	5.9
9	2.7	8.9
12	3.7	12.1

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

	to
Orignal S-57(ENC)		Nuno Navigator

At a smaller scale the difference is even more marked

	to
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