Several clarifications to the text requested - 4

[chris-little]

@joanma747 identified several areas of confusion requiring improvements to the text. These have been split into 8 separate sub-issues:

4. The section "6.6.2. NdArray Objects" defines an n-dimensional datacube. I tried hard to understand the order of the values with respect the axis Names but I'm still unsure. This is a very important aspect and should be crystal clear. o The multiplication of the shape numbers give you the exact number of values but this is not written. o About the number encoding: "Note that common JSON implementations use 64-bit floating point numbers as data type for "values", therefore precision has to be taken into account. For example, only integers within the extent [-2^32, 2^32] can be accurately represented with 64-bit floating point numbers." is not consistent with the IETF RFC. I suggest to align it: “This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers IEEE754 is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(253)+1, (253)-1] are interoperable in the sense that implementations will agree exactly on their numeric values."

[letmaik]

Ordering of values: Maybe we can add to the first bullet point 'The array elements of "values" represent a D-dimensional N_1 x N_2 x ... x N_D array where elements MUST be ordered in row-major order such that an element specified by indices (n_1, n_2, ..., n_D) has the array location n_1 + N_1 (n_2 + N_2 (... + N_{D-1}*n_D)...)).'

Multiplication of shape numbers: Agreed, we should add '... an array of integers which are the dimension sizes N_1, N_2, ..., N_D that when multiplied together MUST equal the number of elements in "values"'.

axisNames: I would at least add '... of the same length as "shape" such that each string assigns a name to the corresponding dimension.'

Number encoding: Agreed, let's change it to [-(2**53)+1, (2**53)-1]. I noticed this before but forgot about it.

@joanma747 Are you happy with that?

[jonblower]

I'll do a PR for this and add @letmaik and @joanma747 as reviewers

[jonblower]

See https://github.com/opengeospatial/CoverageJSON/pull/114

[joanma747]

I'm happy with the direction of the suggested changes. Much more clear now!.

Are you including the IETF RFC. as part of the normative references?

[jonblower]

Are you including the IETF RFC. as part of the normative references?

yes, this is now in the reference list

[chris-little]

PR #114 now merged.