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 <[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
