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

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.

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.

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.

Example Claim S121PT1

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.

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.

S121 Structure Administrative Feature and Attribute Source

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

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)

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.

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.

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.

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.

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 , .

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:   1023 Feature= ExclusiveEconomicZone verdom= water_surface, water_column, seabed_surface, subsoil <EOR>

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

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 

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 ===

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.

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= 1840 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 = http://www.archivescanada.ca/ Beginning of validity=1931:12:11

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 ===

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

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.

Thank You