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.