1. S121 Encodings for interchange
C. D. O’Brien
IDON Technologies
21 September 2017
On behalf of the Canadian Hydrographic Service

2. Introduction
An exchange format is needed for nations to submit of Maritime Limits and Boundaries to the UN Division for Ocean Affairs and the Law of the Sea (DOALOS).
However, submissions must be human readable text that can be understood in a legal environment, not a technical one.
The submission represents a treaty, claim or agreement and there can be no technical barrier preventing legal staff from reading the document.

3. Requirement
The primary requirement is for the information submitted to DOALOS to be clear text that can be easily read in a legal environment.
The secondary requirement is that the submission be machine readable so that it can be read into a database or other computer system, and easily exchanged.

4. XML and structured text
Although the Extensible Markup Language (XML) and some other string based data formats are readable by Information Technology experts without special tools, they are not readable without a lot of training.
Such formats are not suitable for a legal environment.

5. Example Claim
S121PT1

6. Simplicity
A submission to DOALOS should look as close to the printed form of a legal document as possible while still retaining the structured elements of S121.
In order for the document to be computer readable there needs to be keywords and other formatting that can be consistently read by a computer.
A structured text document can look close to the original paper document while still being machine readable.

7. Units
S121 contains a:
Feature Unit object with subtypes
Spatial Attribute object with subtypes
Source object and
Administrative information objects.
Each object type has several attributes and can reference other objects.
This is a relatively small vocabulary, meaning that a structured record oriented format is feasible.
A data exchange format can consist of a set of formatted record types that can be human readable.

8. S121 Structure
Administrative
Feature and Attribute
Source

9. Example Object Type
The Territorial Sea Limit object has 11 attributes, most of which are optional.
This object could be described by a structured text record that identified its type allowed the attributes to be described.
Delimiters could be used to separate fields.
Limit-1 Outer Limit of the Territorial Sea Feature usage = MLB Feature context = Feature context = Calculated from historical survey Releasability = internal use Beginning of validity=1931:12:11 Spatial Curve= Curve-1

10. Referencing
Complex attributes and relationships will require pointers to other records.
A numbering / naming mechanism is needed.
An example code for a geodetic datum could be:
AGD66 (Australian datum 1966) or
NAD 83 (North American Datum 1983)

11. Approaches to encoding
There are several simple formatted text strategies.
The simplest format is Comma/Tab Separated Value
This approach is very tabular
An alternative is “Well Known Text” which is an Open Geospatial Consortium (OGC) standard.
This approach may introduce too many brackets and begin to look like XML.
A third approach is “GeoPackage”
This approach definitely looks too much like XML and is difficult to read.
The trade-off is readability vs flexibility.

12. Delimited Text (CSV) The Delimited Text approach is illustrated below.
In this approach strings of coordinates can be:
x/y, x/y, x/y, x/y, x/y, x/y, x/y, ….
Sub- formatting can allow for D° M' S"/ D° M' S".
Since the majority of data in such a document are X/Y coordinates of points, this is very readable, and familiar to those reading existing paper documents.

13. Record structure
Each record needs to begin with a record number and an identifier of the type and structure of the record.
There also needs to be a record terminator which is explicit and which cannot appear anywhere in the data.
Since the carriage return character may occur in text fields the terminator cannot be a carriage return (CR) character.
In addition there is a need for a terminator for the end of the file.

14. Delimiters
In order for the fields within a record to be clear there need to be explicit delimiters.
Allowing for variable length data fields requires that the delimiters be imbedded in the data.
These delimiters must be printable characters that can be seen in the text.
TAB has a visual effect and therefore can be seen.
TAB (IA5 Code 09)
- Record Field Separator
- (IA5 Code 45)
- Record Identifier Sub-field Separator (used to separate the namespace from the ID number in a record identifier)
= (IA5 Code 61) followed by an optional Space or multiple Space characters (IA5 Code 32)
- Sub-field Separator (used separate the attribute type from the attribute value sub field) The use of optional Space characters makes the data more readable. The use of at least one is recommended.
, (IA5 Code 44) followed by an optional Space or multiple Space characters (IA5 Code 32)
- Sub-sub-field Separator (used for some attributes that contain strings of values) The use of optional Space characters makes the data more readable. The use of at least one is recommended.
/ (IA5 Code 47) followed by an optional Space or multiple Space characters (IA5 Code 32)
- Sub-sub-field Lat/Long Separator (used to for some attributes that contain Lat / Long values) The use of optional Space characters makes the data more readable.

15. Fields and subfields The tab character delimits fields.
In some cases there is a need to identify sub-fields. In this case the delimiter = can be used. The character = would separate a sub-field header from a value.
The character / would separate two numbers in a numeric attribute such as a Latitude and Longitude.
Some subfields, such as attributes may take on a string of attribute values. These attribute values may be separated by a sub-sub-field delimiter , .

16. Feature Type Record
The Feature Type Record allows one to express the features and attributes.
The attribute field can repeat and each field is separated by a TAB character.
The way this would look in a printed text would be very readable. For example:
Feature= ExclusiveEconomicZone verdom= water_surface, water_column, seabed_surface, subsoil <EOR>

17. Feature Type Record Example
The way this would look in a printed text would be very readable. For example:
Location-2 Baseline Point Computational origin = defined Feature context = West end of baseline Releasability= official Beginning of validity= 2009:06:01 Spatial Point = Point-2
Point-2 Position= 52°15′30″N/55°32′58″W Coordinate Reference System= WGS84 Beginning of validity = 2017:01:01

18. Example 1
The following is an example simple dataset consisting of only two control points. The lead-in metadata for the example dataset has not been included. This example contains only two types of records:
Location Feature Type Record
Point Spatial Attribute Record 

19. Example 1 Detail
Location-1 Baseline Point Computational origin = defined Feature context = East end of baseline Releasability= official Beginning of validity=2017:01:01 Spatial Point= Point-1
Location-2 Baseline Point Computational origin = defined Feature context = West end of baseline Releasability= official Beginning of validity= 2009:06:01 Spatial Point = Point-2
Point-1 Position= 52°15′30″N/55°32′58″W Coordinate Reference System= WGS84 Beginning of validity = 2017:01:01
Point-2 Position= 52°26′37″N/55°37′40″W Coordinate Reference System= WGS84 Beginning of validity = 2009:06:01
=== End of File ===

20. Example 2
The following is an example simple dataset consisting of only the Territorial Sea Zone bounded by the Outer Limit of the Territorial Sea.
The other boundaries of the Territorial Sea are described as Location By Text since they are not explicitly given.
The landward limit is simply described as the coast.
A minimum of lead-in metadata is included.

21. Example 2 Detail Title Example Data Set Language English
Security Classification Unclassified
Zone-1 Territorial Sea Vertical Domain= water_surface, water_column, seabed_surface, subsoil Feature usage= MLB Releasability= official Beginning of validity= Spatial Surface= Surface-1 Plus Boundary= Limit-1, Limit-2
Surface-1 Coordinate Reference System= WGS84 Beginning of validity = 1840:06 Surface Source=Source-1
Source-1 Spatial Source Spatial source type = historical document Source name = Based on work by Sir John Franklin Source acceptance date = 1840:06:01 Responsible party organization name = Library and Archive Canada Source online locator = Beginning of validity=1931:12:11

22. Example 2 Detail 2
Limit-1 Outer Limit of the Territorial Sea Feature usage = MLB Feature context = Feature context = Calculated from historical survey Releasability = internal use Beginning of validity=1931:12:11 Spatial Curve= Curve-1
Limit-2 Limit Feature usage = MLB Feature context= Generic closing limit Releasability= internal use Spatial Curve= Curve-2
Curve-1 Line lat1/long1, lat2/long2, lat3, long3, …. Coordinate Reference System= WGS84 Beginning of validity = 1931:12:11
Curve-2 Location by text= closing line including the coastline and adjacent sides Beginning of validity = 1931:12:11
=== End of File ===

23. Portrayal
The encoding format can be read by anyone but it is not “pretty”. It still looks like structured text.
According to the ISO TC211 Reference Model geospatial data consists of :
Metadata,
Features and Attributes,
Application Schema (relationship model),
Spatial Referencing,
Encoding and
Portrayal
All of the elements have been addressed except for portrayal

24. Portrayal 2
Portrayal can be used to format the encoding to make it look very close to the existing printed legal documents.
The portrayal can follow the ISO and IHO portrayal standards, but of course the portrayal details will be different from the portrayal rules of S.101.

25. Thank You