My bad:
"As of version 4.6.3, NCO defaults to demarcate inner dimensions of
variable data with (nested) square brackets rather than printing data as an
unrolled single dimensional array."
So we will seriously consider the change of data location, "dimensions" to
"shape", and then CF-JSON=NCO v4.6.3+ lvl0 (I think...)
This would at least bring these two together with minimal effort.
The bigger potential merge and or migration to CovJSON is another question.
Just to be clear, we have no real agenda to promote any particular scheme,
but do need a stable specification to give to API customers. And happy to
help out with publicizing and tooling a community decision.
Further development of these ideas is probably getting outside the intended
purpose of this list, so someone feel free to boot this conversation
elsewhere.
On Thu, Jul 27, 2017 at 4:33 PM, David Johnson <d.johnson at metocean.co.nz>
wrote:
> Hi All,
>
> The CF-JSON structure was generally based on CDL (as produced by ncdump)
> which stores the data in a separate section. The key requirement is the
> same as for CDL.
>
> But I do see the logic of just including it in the variable section
> itself.
>
> I haven't had a chance to properly review NCO JSON, but it sounds like we
> may be very close. This Is there a published specification anywhere? - so
> far I have just looked at various actual file dumps.
>
> One thing I prefer about CF-JSON is the multidimensional arrays. Both NCO
> and CovJSON have flattened arrays (as does CDL). I think web devs would
> probably prefer the former and there is less chance of an array wrangling
> mistake. I also like the option to dump time as ISO8601 because again I
> think web devs appreciate the ease of this rather than having to support
> time conversions and calendar issues.
>
> We are at an early stage so could easily merge.
>
> Dave
>
> On Thu, Jul 27, 2017 at 12:30 PM, Chris Barker <chris.barker at noaa.gov>
> wrote:
>
>> Just looked a tiny bit more at CF_JSON, and see an issue right away:
>>
>> "The data object contains the actual data for each variable as its
>> key:value members. Each data key MUST be the same as it variable ID key."
>>
>> {
>> ...
>> "variables": {
>> "tmp2m": {
>> "dimensions": ["time","latitude","longitude"]
>> }
>> ...
>> "data": {
>> "tmp2m": [
>> [[1.2,3.4,5.6 ...],
>> [2.3,6.5,8.7 ...],
>> ...
>> ],
>> ]
>> ...
>> }
>>
>> JSON can be arbitrarily nested -- so why store the "data" object
>> separately from the variable objects, using a key to map them?
>>
>> why not:
>>
>> {
>> ...
>> "variables": { "tmp2m": {"dimensions": ["time","latitude","longitude"
>> ]
>> "attributes": {"units": "ms^{-1}",
>> "long_name": "Easterly
>> component of wind",
>> "standard_name":
>> "eastward_wind"
>> },
>> "data": [[1.2,3.4,5.6 ...],
>> [2.3,6.5,8.7 ...],
>> ...
>> ],
>> },
>> ...
>> }
>> }
>>
>> I think that's more or less how NCO's JSON works, and it keeps everything
>> about a variable all in one place -- easier for parsing tools, etc. And
>> maps well to the Python netCDF4 data structure anyway.
>>
>> -CHB
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chris.Barker at noaa.gov
>>
>
>
>
> --
>
> [image: MetOcean Solutions Ltd] <http://www.metocean.co.nz/>
>
> *Dr David Johnson*
> Technical Director
> t: +64 7 825 0540 ext.1 <http://+6467585035/>02
> m: +64 2 <http://+64276853473/>1 057 1058
> www.metocean.co.nz
>
--
[image: MetOcean Solutions Ltd] <http://www.metocean.co.nz/>
*Dr David Johnson*
Technical Director
t: +64 7 825 0540 ext.1 <http://+6467585035/>02
m: +64 2 <http://+64276853473/>1 057 1058
www.metocean.co.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170727/8d65ca0a/attachment.html>
Received on Wed Jul 26 2017 - 23:17:59 BST
