SWE Common Data Model OGC 08-094r1
9.4 Requirements Class: Binary Encoding Rules Requirements Class
http:www.opengis.netspecSWE2.0reqbinary-encoding-rules
Target Type Encoded Values Instance
Dependency
http:www.opengis.netspecSWE2.0requml-advanced-encodings
Dependency
http:www.opengis.netspecSWE2.0reqgeneral-encoding-rules
The “BinaryEncoding” method encodes field values by their binary representation. The ABNF syntax defined in IETF RFC 5234 is used to formalize the encoding rules, and
thus all ABNF snippets provided in this section are normative.
Requirement
http:www.opengis.netspecSWE2.0reqbinary-encoding-rulesabnf-syntax-valid
Req 101. The encoded values block shall be formatted as defined by the ABNF
grammar defined in this clause.
The encoding rules are similar to those of the “TextEncoding” method except that numerical values are encoded directly as their binary representation and that no
separators are used. Separators are not needed because data types have either a fixed size or contain length information See String encoding.
9.4.1 Rules for Scalar Components
The value for a scalar component is encoded as its binary representation. This especially applies to numerical values that are encoded directly in binary form in accordance to the
selected data type and the value of the “byteOrder” attribute.
scalar-value = binary value encoded according to data type, byte encoding and byte order specifications
The last column of Table 8.1 in clause 8.6.1 indicates how each data type shall be binary encoded into a low level byte sequence. The actual order of bytes composing a multi-
bytes data type depends on the value of the “byteOrder” attribute. The ‘bigEndian’ option indicates that muti-bytes data types are encoded with the most significant byte MSB
first, while selecting ‘littleEndian’ signifies that encoding is done with the less significant byte LSB first. A UTF-8 string is not considered as a multi-byte data type and is always
encoded in the same order, as specified by the Unicode Standard.
Copyright © 2011 Open Geospatial Consortium
133
OGC 08-094r1 SWE Common Data Model
Requirement
http:www.opengis.netspecSWE2.0reqbinary-encoding-rulestype-encoding-valid
Req 102. Binary data types in Table 8.1 shall be encoded according to their
definition in the description column and the value of the “byteOrder” attribute.
Nil values are included in the stream just like normal scalar values. Since their data type has to match the field data type, there is no special treatment necessary for a decoder or
encoder. It is the responsibility of the application to match the data value against the list of registered nil values for a given field in order to detect if it is associated to a nil reason
or if it is an actual measurement value.
When the ‘raw’ byte encoding option is selected, bytes resulting from the data type encoding process defined above are inserted in the binary stream directly. This is refered
to as ‘raw binary’ encoding. When the ‘base64’ option is selected, each byte resulting from the binary encoding process is also encoded in Base64 before being included in the
stream. Scalar values can be Base 64 encoded one by one or by blocks as long as the resulting stream is compatible with requirements of IETF RFC 2045.
Requirement
http:www.opengis.netspecSWE2.0reqbinary-encoding-rulesbase64-translation-applied
Req 103. When the ‘base64’ encoding option is selected, binary data shall be
encoded with the Base64 technique defined in IETF RFC 2045 Section 6.8: Base64
Content ‐Transfer‐Encoding.
9.4.2 Rules for Range Components
Range components are encoded as a sequence of two binary values each one representing a scalar value:
min-value = scalar-value max-value = scalar-value
range-values = min-value max-value
Values are always included in the same order: The lower bound of the range first, followed by the upper bound.
9.4.3 Rules for DataRecord and Vector
Values of fields of a “DataRecord” are recursively encoded following rules associated to the type of component used as the field’s description i.e. scalar, record, array, etc. and
appended to the binary block:
134
Copyright © 2011 Open Geospatial Consortium