Just to round this out for now:
We have released version 0.2 of our CF-JSON spec (
http://cf-json.org/specification) to merge with the NCO format. So CF-JSON
is now consistent with NCO JSON output. CF-JSON does not currently
*require* all of the NCO JSON elements, but NCO JSON is valid CF-JSON.
The intention is to try and stay compatible with the NCO going forward,
providing there are no major breaking changes. So now we are down to 2
specifications.
We can continue the covJSON discussion on their github repo.
On Thu, Jul 27, 2017 at 5:17 PM, David Johnson <d.johnson at metocean.co.nz>
wrote:
> 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
>
--
[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/20170802/3397333a/attachment.html>
Received on Tue Aug 01 2017 - 14:26:13 BST
