5.3.2.1 ChannelData Element

The bulk data for an individual ChannelSet within a Log is sent as a JSON-compatible set of arrays within the ChannelData XML element. By JSON-compatible, we simply mean the data block could be processed by a JSON.parse() function. The data block (at this time) does not use the full features of JSON.

The size, dimensionality and expected datatype of the arrays can be derived from the descriptions of the Channels in the ChannelSet. To serialize data, follow these rules:

1. Whitespace is not significant, but it is recommended that individual rows are on a single line, for readability. This rule becomes irrelevant for large array channels.
2. Arrays are delimited by square brackets; array elements are delimited by commas.

[123, 456, 7.89]

1. Strings are in double quotes with backslash escaping.

[123, “hello”]

1. As in JSON, null values are represented by the word null itself (case sensitive). This is a significant change from WITSML 1.x, where consecutive commas designated no data.
2. Dates and times (in particular, time index values) are strings in ISO 8601 format. As in ETP, all time index values must be UTC.
3. In general, where the expected size of an array is known from the metadata and the actual size of the array is smaller, then the remaining elements of the array are assumed to be null. For instance, if a set has 12 channels and a given data has 8 elements, the final four channel values are null.
4. The entire data block is enclosed in a top-level array which represents the entire data set.

[
]

1. Each element of that array is itself an array representing one ‘row’ of log data. That is, an index (or indexes) and all of the channel values for that index. These correspond to one <data/> tag in WITSML 1.4.1.1 logs.

[
[First row of data],
[Second row of data],
[Third row of data]
]

1. Within a data row, the index value(s) are distinctly separated from the channel values as an array. This is also in contrast to the earlier formats where the index was simply another channel that was identified as being the index and had to be identified by array position.

[
[[Index Values], [Channel Values]],
[[Index Values], [Channel Values]],
[[Index Values], [Channel Values]]
]

Putting together these requirements and rules, a section of a simple gamma log, with a primary depth index, a secondary time index, and two data channels GR1AX, GR2AX might look like this:

[
[[2496.840,”2009-06-22T05:21:03.0000000Z”], [53.9, 49.3]],
[[2497.500,”2009-06-22T05:34:30.0000000Z”], [55.3, 50.6]],
[[2498.053,”2009-06-22T06:59:31.0000000Z”], [54.9, 50.2]],
[[2500.099,”2009-06-22T06:39:56.0000000Z”], [56.8, 51.9]],
[[2500.621,”2009-06-22T07:06:02.0000000Z”], [50.5, 46.2]],
[[2501.001,”2009-06-22T06:46:28.0000000Z”], [52.9, 48.4]],
[[2501.141,”2009-06-22T06:26:54.0000000Z”], [60.6, 55.5]],
[[2503.449,”2009-06-22T06:13:51.0000000Z”], [null, 49.3]],
[[2503.774,”2009-06-22T11:15:19.0000000Z”], [50.5, 46.2]],
[[2504.228,”2009-06-22T06:20:24.0000000Z”], [59.2, 54.1]],
[[2504.237,”2009-06-22T07:12:31.0000000Z”], [52.5, 48]],
[[2504.272,”2009-06-22T06:33:26.0000000Z”], [52.5, 48]]
]

1. When the Channel value itself is an array, it is simply written that way. If the Channel array is multi-dimensional, the dimensionality is not reflected in the data block. It is simply an array whose size is the product of the size of all dimensions described in the AxisDefintions of the Channel.
2. If a Channel contains value-level metadata (such as quality, confidence, etc.) as described in the PointMetadata element of the Channel, then the values for that channel are themselves an array in which the first element is the Channel value and the remaining elements are the point metadata. Using the example above, if the GR1AX channel described point metadata of ‘confidence factor’ as floating point number, it might look like this:

[
[[2496.840,”2009-06-22T05:21:03.0000000Z”], [[53.9, 0.9], 49.3]],
[[2497.500,”2009-06-22T05:34:30.0000000Z”], [[55.3, 0.9], 50.6]],
[[2498.053,”2009-06-22T06:59:31.0000000Z”], [[54.9 ], 50.2]],
[[2500.099,”2009-06-22T06:39:56.0000000Z”], [[56.8, 0.9], 51.9]],
[[2500.621,”2009-06-22T07:06:02.0000000Z”], [[50.5, 0.9], 46.2]],
[[2501.001,”2009-06-22T06:46:28.0000000Z”], [[52.9, 0.9], 48.4]],
[[2501.141,”2009-06-22T06:26:54.0000000Z”], [[60.6, 0.9], 55.5]],
[[2503.449,”2009-06-22T06:13:51.0000000Z”], [null , 49.3]],
[[2503.774,”2009-06-22T11:15:19.0000000Z”], [[50.5, 0.9], 46.2]],
[[2504.228,”2009-06-22T06:20:24.0000000Z”], [[59.2, 0.9], 54.1]],
[[2504.237,”2009-06-22T07:12:31.0000000Z”], [[52.5, 0.9], 48]],
[[2504.272,”2009-06-22T06:33:26.0000000Z”], [[52.5, 0.9], 48]]
]

Some things to note.

• If PointMetadata exists on the ChannelDefinition, then all values MUST appear as an array in the data set, whether the metadata exists for that specific point or not.
• If the entire point does not exist, you can still simply use null.

• If a given point has no metadata (as in the 3rd row), then it can simply be left off.

1. It is a recommended practice to enclose the entire data block in a CDATA section, particularly if there are Channels with human-editable contents, such as comments or messages. For this purpose it is import to leave whitespace between the square brackets of the CDATA section and those of the array.

<![CDATA[ 
[
[[2496.840,”2009-06-22T05:21:03.0000000Z”], [[53.9, 0.9], 49.3]],
[[2497.500,”2009-06-22T05:34:30.0000000Z”], [[55.3, 0.9], 50.6]],
[[2498.053,”2009-06-22T06:59:31.0000000Z”], [[54.9 ], 50.2]],
[[2500.099,”2009-06-22T06:39:56.0000000Z”], [[56.8, 0.9], 51.9]],
[[2500.621,”2009-06-22T07:06:02.0000000Z”], [[50.5, 0.9], 46.2]],
[[2501.001,”2009-06-22T06:46:28.0000000Z”], [[52.9, 0.9], 48.4]],
[[2501.141,”2009-06-22T06:26:54.0000000Z”], [[60.6, 0.9], 55.5]],
[[2503.449,”2009-06-22T06:13:51.0000000Z”], [null , 49.3]],
[[2503.774,”2009-06-22T11:15:19.0000000Z”], [[50.5, 0.9], 46.2]],
[[2504.228,”2009-06-22T06:20:24.0000000Z”], [[59.2, 0.9], 54.1]],
[[2504.237,”2009-06-22T07:12:31.0000000Z”], [[52.5, 0.9], 48]],
[[2504.272,”2009-06-22T06:33:26.0000000Z”], [[52.5, 0.9], 48]]
]
]]>