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
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
