Between GIS and ECDIS, S-57 and S-52 for marine and military fields

Among GIS tools it is unusual to find support for navy and military formats. In this post I will present you one of those with its specific symbology.

1. IHO specifications

The International Hydrographic Organization has published a lot of documents and specifications related to sensors, security, symbology, vector and raster formats. The complete list is available at http://www.iho.int/iho_pubs/IHO_Download.htm

In this article we are going to focus on two of the most used specifications :

• S-57 : the vector format
• S-52 : the chart symbology

Those two are the core elements of what define an ECDIS. ECDIS stands for Electronic Chart Display and Information System, to make it simple, all middle size and large boats are equiped with this system which displays information like boat position, shores, bathymetry, lighthouses, beacons, restricted areas, depth, navigation roads, …. and many more.

2. S-57  Vector format

The format itself is pretty long to describe, with the main specification and  annexes it gets close to a thousand pages.

So here are its key characteristics :

• ASCII based mixed with Non-ASCII delimiters
• Support spaghetti, chained or topologic geometries

• Support incremental updates and versionning
• Support geographic partitionning on multiple files
• Records types and fields listed as tables
• New record types and fields can be defined in other documents or can be ignored
• Records can define there own symbology rendering procedures

As you can see, S-57 version 3 has a lot interesting properties we don’t see in usual GIS formats. Despite being old (1996) and not using advanced compression techniques, the files are very dense and a few kilobytes contain a lot of information. Even if the format supports topologic geometries, in the last years I never encountered any file using it therefore I believe this last design model is to complex to manipulate and encode for data producers.

The baseline S-57 contains ~150 different record types and ~200 different possible fields.

With the extensions Additional Military Layers (AML) and Mariner objects we obtain over 250 record types and 500 fields !

On a more programming level, we have mapped Record types as OGC Feature Types and fields as Attributes following the GeoAPI interfaces, so that no information is lost in the mapping process.

Here is an example of the visual result of file : US4CA60M (2Mb)

There is so much information that we can barely understand what we are looking at.

3. S-52  Symbology

We have seen that S-57 is really dense and without a proper symbology, the user will get lost in all informations, this is were S-52 comes in.

To achieve S-52 rendering we used the extendable API of the 2D rendering engine. When you create a style, rather then using OGC PointSymbolizer, LineSymbolizer or PolygonSymbolizer, we have a new S52Symbolizer. The API mechanic makes it possible to define new symbolizers and save them in SLD file.

For those used to SLD, here is what the S-52 symbolizer looks like :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sld:UserStyle xmlns:se="http://www.opengis.net/se" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:ns6="http://geotoolkit.org" xmlns:ns8="http://www.opengis.net/gml/3.2">
  <se:Description>
    <se:Title></se:Title>
    <se:Abstract></se:Abstract>
  </se:Description>
  <sld:IsDefault>false</sld:IsDefault>
  <se:FeatureTypeStyle>
    <se:Description>
      <se:Title></se:Title>
      <se:Abstract></se:Abstract>
    </se:Description>
    <se:Rule>
      <se:Description>
        <se:Title></se:Title>
        <se:Abstract></se:Abstract>
      </se:Description>
      <se:MinScaleDenominator>0.0</se:MinScaleDenominator>
      <se:MaxScaleDenominator>1.7976931348623157E308</se:MaxScaleDenominator>
      <ns6:S52Symbolizer>
        <Configuration>
          <DisplayChartCategory>STANDARD</DisplayChartCategory>
          <DisplayMarinerCategory>MARINERS STANDARD</DisplayMarinerCategory>
          <Palette>DAY</Palette>
          <AreaLookupTable>PLAIN_BOUNDARIES</AreaLookupTable>
          <LineLookupTable>LINES</LineLookupTable>
          <PointLookupTable>SIMPLIFIED</PointLookupTable>
          <NoText>false</NoText>
          <SafetyDepth>30.0</SafetyDepth>
          <ShallowContour>2.0</ShallowContour>
          <SafetyContour>30.0</SafetyContour>
          <DeepContour>30.0</DeepContour>
          <LowAccuracySymbol>false</LowAccuracySymbol>
          <TwoShade>true</TwoShade>
          <ShallowPattern>false</ShallowPattern>
          <ShipOutline>false</ShipOutline>
          <ContourLabel>true</ContourLabel>
          <SafetyContourLabel>true</SafetyContourLabel>
          <TimeTag>0.0</TimeTag>
          <FullSector>true</FullSector>
          <LightDescription>false</LightDescription>
          <DangerShallowWater>false</DangerShallowWater>
          <AnalyzeDepth>0.0</AnalyzeDepth>
          <ScaleFilter>true</ScaleFilter>
        </Configuration>
      </ns6:S52Symbolizer>
    </se:Rule>
  </se:FeatureTypeStyle>
</sld:UserStyle>

Why not replace S-52 by the usual OGC Symbology Encoding and SLD files ?

The reason is straight forward, SLD can’t render S-52, it would be able to map perhaps 80% of S-52, but, for many reasons, this would result in very complex style rules and functions. More than that, some elements are related between them. For example, reefs do not have the same icon if they are in deep sea or in shallow water, that means we must know what other feature of other types are intersecting. Lighthouses and beacons show sectors in real length units, and many rendering procedures would not be possible to express as SLD.

This is what S-52 calls a rendering procedure, (and this is only half of the LIGHTS05 procedure) :

 

Now, let’s change the style of the above data and check the result :

It is much more readable now and this is only the basic configuration, many properties can be configured such as text size and color, palette, visible elements,etc.

Among those properties, S-52 defines palettes : DAY, DUSK and NIGHT which have been studied to ensure a good visibility with low or no light. The above image in dusk mode looks like :

4. Style editor

Among all requirements of ECDIS, one concerns user interfaces. The user must be able to adjust the rendering, changing text visibility, size, color …. show or hide some specific types of features, configure his ship informations, which have an effect on the rendering.

Aside the configuration, several static pieces of information must also remain available, like a catalog of S-52 symbols and their meaning.

To fullfil this objective, the SLD editor has been enhanced with a S-52 Symbolizer editor which provides those informations.

• Global parameters

• Feature type filters

• Palette colors

• S-52 symbol table

 

5. Conclusions

The navy tools and formats have a lot in common with our usual GIS ones, strangely those two worlds are still separate, not because of formats but because the communities are also divided. ECDIS maps are self-sufficiant, they can live on their own without side information unlike in classic GIS, where mixing datas from various sources is a De Facto. Because of that, ECDIS users only use regular data updates from their usual source and that’s it.

Compared with OGC GML, KML, Geodatabase or good old shapefile, S-57 totally has the upper-hand. I might be old but it has a much more advanced design and solves several of the problems we fight with nowadays like versioning, topology and geographic partitioning. If S-57 was cleaned up using the latest algorithm and encoding methods it would surely supersede all the GIS file vector formats on many aspects.

S-52 is awfully complex but it is the result of decades of mariner expertise on navigation map symbology and has become a De Facto worldwide standard for navigation maps. Styling over two hundred feature types on different scales and collecting all those procedures must have taken years of work. As a GIS specialist and developer I can only admire the result, even colors have been studied to ensure it doesn’t bother the user at any time.

Well that’s it, I hope you appreciate this post. 😉