On Tue, Aug 1, 2017 at 1:26 PM, David Johnson <d.johnson at metocean.co.nz>
wrote:
> 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.
>
nice work!
-CHB
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170801/e5a4838f/attachment.html>
Received on Tue Aug 01 2017 - 14:52:27 BST
