[CF-metadata] JSON representation based on CF

David Johnson d.johnson at metocean.co.nz
Tue Aug 1 14:26:13 MDT 2017


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-0001.html>


More information about the CF-metadata mailing list