On Tue, Aug 1, 2017 at 1:26 PM, David Johnson <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> >>> [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 > [email protected] > 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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
