Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread David Johnson
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 
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 
> 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(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>>
>> chris.bar...@noaa.gov
>>
>
>
>
> --
>
> [image: MetOcean Solutions Ltd] 
>
> *Dr David Johnson*
> Technical Director
> t: +64 7 825 0540 ext.1 02
> m: +64 2 1 057 1058
> www.metocean.co.nz
>



-- 

[image: MetOcean Solutions Ltd] 

*Dr David Johnson*
Technical Director
t: +64 7 825 0540 ext.1 02
m: +64 2 1 057 1058
www.metocean.co.nz
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread David Johnson
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 
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(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>



-- 

[image: MetOcean Solutions Ltd] 

*Dr David Johnson*
Technical Director
t: +64 7 825 0540 ext.1 02
m: +64 2 1 057 1058
www.metocean.co.nz
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread Chris Barker
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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread Chris Barker
At a really quick glance, it looks like CovJSON has a different mission
that "CF-json" or "netcdf-json". But they do sure overlap, so I hope we can
not have TOO many overlapping yet different JSON specs out there.

None of these are very mature or widely adopted -- so now it a good time
(indeed the ONLY time to merge some of this.

CF-JSON looks a little bit like a misnomer, or a maybe a different focus
that what I'd expect. What I"ve getting at is that CF is a metadata spec
(and maybe a data model) -- while it is quite tied to netcdf, it ISN'T
netcdf per se.

So if you what to express that kind of information in JSON, I think the
thing to do is specify how to map netcdf to JSON, and then simply apply the
same CF metadata standards.

Which is what NCO has done.

One couldn't of course, express the CF data model in JSON directly, without
specifically mapping to netcdf, though I think that would look very
similar, but not be as generally applicable.

At a quick glance, NCO's JSON and the CF-JSON spec are similar -- after
all, they are tryn gto do teh same thing -- but there are a lot of niggling
details to settle on, and I can only imagine independent efforts came up
with different solutions.

So I hope that the two groups (and the covjson folks) can get together and
converge to one thing!

-CHB







On Wed, Jul 26, 2017 at 9:13 AM, Jon Blower 
wrote:

> Hi all,
>
>
>
> Just to introduce myself – I managed the project [1] that yielded CovJSON
> [2]. It was developed mostly by my colleague Maik Riechert, with occasional
> input from me. We managed to get it to a reasonable state of maturity, but
> it would be great to see wider uptake – I’m very happy to provide advice on
> this, for example to support implementation in TDS, which would be great
> (we already have some libraries that might help here, although they are not
> complete).
>
>
>
> In retrospect, I should have announced our progress on this list, although
> it wasn’t specifically CF-related. Apologies for that. The work was done
> partly within a joint OGC/W3C working group [3], and some members of the
> CF/NetCDF community were part of this.
>
>
>
> My plan is to set up a working group for CovJSON, perhaps under the
> auspices of the OGC’s incubator programme, with a view to ultimately
> producing a standard. When this happens, I’ll be sure to invite members of
> this list to participate, as it would be great to have a wider group of
> people providing input.
>
>
>
> David (and indeed anyone) – please feel free to make any comments on
> CovJSON. You can do this via email to me, or by raising an issue on the
> appropriate GitHub repositories [4].
>
>
>
> CovJSON at the moment probably can’t cover the whole gamut of what is
> possible with CF. Things like cell methods, climatological time and a few
> other things are not supported. The focus was not on implementing CF in its
> entirety, but producing a (reasonably) simple JSON format to support the
> development of interactive websites. Some of the finer points of CF are
> less important for this kind of application. This could be a good topic of
> discussion in the incubator group.
>
>
>
> There is a presentation [5] and overview slides [6], which might be a good
> way to get an overview of this project.
>
>
>
> Hope this helps,
> Jon
>
>
>
> [1] http://www.melodiesproject.eu
>
> [2] https://covjson.org
>
> [3] https://www.w3.org/2015/spatial/wiki/Main_Page
>
> [4] https://github.com/covjson
>
> [5] https://ecmwf.adobeconnect.com/p6224btxzng/
>
> [6] https://www.ecmwf.int/sites/default/files/elibrary/2017/
> 17149-building-rich-and-interactive-web-applications-coveragejson.pdf
>
>
>
> *Jon Blower *| CTO, Institute for Environmental Analytics
>
>
>
> Follow the IEA on Twitter @env_analytics
>  and on LinkedIn The Institute for
> Environmental Analytics (IEA)
> 
>
>
>
> Philip Lyle Building, University of Reading, Whiteknights Campus, Reading
> RG6 6BX
>
> *T: *+44 (0)118 378 5213 <+44%20118%20378%205213> *M: *+44 (0)7919 112687
> <+44%207919%20112687>
>
> *E: *j.blo...@the-iea.org *W: *www.the-iea.org
>
>
>
> *From: *CF-metadata  on behalf of David
> Johnson 
> *Date: *Wednesday, 26 July 2017 02:01
> *To: *Sean Arms 
> *Cc: *"cf-metadata@cgd.ucar.edu" 
> *Subject: *Re: [CF-metadata] JSON representation based on CF
>
>
>
> Hi Sean,
>
>
>
> Thanks very much for that reference. CovJSON looks really good, and fairly
> mature. Pity we weren't aware of this and didn't check this out a couple of
> months ago!.
>
>
>
> I think this would probably provide a full one-to-one mapping to
> CF-NetCDF, which I think some will want. And seems to cover all the 

Re: [CF-metadata] Advancing netCDF-CF workshop on 6-8 Sept 2017 in Boulder, CO USA

2017-07-26 Thread Ethan Davis
Hi Antonio,

Yes, we will have remote participation available.

Cheers,

Ethan

On Wed, Jul 26, 2017 at 1:28 PM, Antonio S. Cofiño  wrote:

> Hi Ethan,
>
> There is any chance to enable remote virtual participation into this
> workshop?
>
> Thank you and regards
>
> Antonio
>
>
> --
> Antonio S. Cofiño
> Associate Professor and Researcher
> Grupo de Meteorología de Santander
> Dep. of Applied Mathematics and Computer Sciences
> Universidad de Cantabria (Spain)
>
> Academic Visitor
> National Centre for Atmospheric Science
> Department of Meteorology
> School of Mathematical, Physical and Computational Sciences
> University of Reading (UK)
> http://antonio.cofino.es
>
> On 26/07/17 18:10, Ethan Davis wrote:
>
> Hi all,
>
> As many of you know, we are holding an "Advancing netCDF-CF" workshop [1]
> on 6-8 September 2017 at UCAR in Boulder, CO USA. This workshop will focus
> on efforts to advance the Climate and Forecast (CF) metadata conventions
> for netCDF (netCDF-CF). The meeting is being hosted by the EarthCube
> “Advancing netCDF-CF for Geoscience” project, which is funded by the US
> National Science Foundation's EarthCube program.
>
> The main focus will be on recent and ongoing efforts to advance netCDF-CF.
> There will be time devoted to several current proposals: satellite swath
> data, group hierarchies, and geometries (e.g., ploylines and polygons).
> There will also be sessions on more general CF topics including the
> recently proposed CF Data Model, ongoing work looking at how to use
> features of the netCDF enhanced data model (string vs char, VLen, etc.),
> and possible change to the latitude/longitude requirement. A detailed
> schedule [2] will be available shortly.
>
> Hotel and other travel information is available on the web site [3]. If
> you plan to attend, please register for the workshop [4]. (There is no
> registration fee, but we do need to know who will be attending and want to
> ensure that everyone attending gets all the relevant workshop details.)
>
> Thanks,
>
> The Workshop Organizing Team
>
> [1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#home
>
> [2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule
>
> [3] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel
>
> [4] http://www.unidata.ucar.edu/events/2017CFWorkshop/#reginfo
>
>
> ___
> CF-metadata mailing 
> listcf-metad...@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


Re: [CF-metadata] Advancing netCDF-CF workshop on 6-8 Sept 2017 in Boulder, CO USA

2017-07-26 Thread Antonio S . Cofiño

Hi Ethan,

There is any chance to enable remote virtual participation into this 
workshop?


Thank you and regards

Antonio


--
Antonio S. Cofiño
Associate Professor and Researcher
Grupo de Meteorología de Santander
Dep. of Applied Mathematics and Computer Sciences
Universidad de Cantabria (Spain)

Academic Visitor
National Centre for Atmospheric Science
Department of Meteorology
School of Mathematical, Physical and Computational Sciences
University of Reading (UK)

http://antonio.cofino.es

On 26/07/17 18:10, Ethan Davis wrote:

Hi all,

As many of you know, we are holding an "Advancing netCDF-CF" workshop 
[1] on 6-8 September 2017 at UCAR in Boulder, CO USA. This workshop 
will focus on efforts to advance the Climate and Forecast (CF) 
metadata conventions for netCDF (netCDF-CF). The meeting is being 
hosted by the EarthCube “Advancing netCDF-CF for Geoscience” project, 
which is funded by the US National Science Foundation's EarthCube program.


The main focus will be on recent and ongoing efforts to advance 
netCDF-CF. There will be time devoted to several current proposals: 
satellite swath data, group hierarchies, and geometries (e.g., 
ploylines and polygons). There will also be sessions on more general 
CF topics including the recently proposed CF Data Model, ongoing work 
looking at how to use features of the netCDF enhanced data model 
(string vs char, VLen, etc.), and possible change to the 
latitude/longitude requirement. A detailed schedule [2] will be 
available shortly.


Hotel and other travel information is available on the web site [3]. 
If you plan to attend, please register for the workshop [4]. (There is 
no registration fee, but we do need to know who will be attending and 
want to ensure that everyone attending gets all the relevant workshop 
details.)


Thanks,

The Workshop Organizing Team

[1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#home

[2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule

[3] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel

[4] http://www.unidata.ucar.edu/events/2017CFWorkshop/#reginfo


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


[CF-metadata] Advancing netCDF-CF workshop on 6-8 Sept 2017 in Boulder, CO USA

2017-07-26 Thread Ethan Davis
Hi all,

As many of you know, we are holding an "Advancing netCDF-CF" workshop [1]
on 6-8 September 2017 at UCAR in Boulder, CO USA. This workshop will focus
on efforts to advance the Climate and Forecast (CF) metadata conventions
for netCDF (netCDF-CF). The meeting is being hosted by the EarthCube
“Advancing netCDF-CF for Geoscience” project, which is funded by the US
National Science Foundation's EarthCube program.

The main focus will be on recent and ongoing efforts to advance netCDF-CF.
There will be time devoted to several current proposals: satellite swath
data, group hierarchies, and geometries (e.g., ploylines and polygons).
There will also be sessions on more general CF topics including the
recently proposed CF Data Model, ongoing work looking at how to use
features of the netCDF enhanced data model (string vs char, VLen, etc.),
and possible change to the latitude/longitude requirement. A detailed
schedule [2] will be available shortly.

Hotel and other travel information is available on the web site [3]. If you
plan to attend, please register for the workshop [4]. (There is no
registration fee, but we do need to know who will be attending and want to
ensure that everyone attending gets all the relevant workshop details.)

Thanks,

The Workshop Organizing Team

[1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#home

[2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule

[3] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel

[4] http://www.unidata.ucar.edu/events/2017CFWorkshop/#reginfo
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread Jon Blower




Hi all,
 
Just to introduce myself – I managed the project [1] that yielded CovJSON [2]. It was developed mostly by my colleague Maik Riechert, with occasional input from me. We managed to get it
 to a reasonable state of maturity, but it would be great to see wider uptake – I’m very happy to provide advice on this, for example to support implementation in TDS, which would be great (we already have some libraries that might help here, although they
 are not complete).
 
In retrospect, I should have announced our progress on this list, although it wasn’t specifically CF-related. Apologies for that. The work was done partly within a joint OGC/W3C working
 group [3], and some members of the CF/NetCDF community were part of this.
 
My plan is to set up a working group for CovJSON, perhaps under the auspices of the OGC’s incubator programme, with a view to ultimately producing a standard. When this happens, I’ll be
 sure to invite members of this list to participate, as it would be great to have a wider group of people providing input.
 
David (and indeed anyone) – please feel free to make any comments on CovJSON. You can do this via email to me, or by raising an issue on the appropriate GitHub repositories [4].
 
CovJSON at the moment probably can’t cover the whole gamut of what is possible with CF. Things like cell methods, climatological time and a few other things are not supported. The focus
 was not on implementing CF in its entirety, but producing a (reasonably) simple JSON format to support the development of interactive websites. Some of the finer points of CF are less important for this kind of application. This could be a good topic of discussion
 in the incubator group.
 
There is a presentation [5] and overview slides [6], which might be a good way to get an overview of this project.
 
Hope this helps,
Jon
 
[1] 
http://www.melodiesproject.eu
[2] 
https://covjson.org 
[3] 
https://www.w3.org/2015/spatial/wiki/Main_Page 
[4] 
https://github.com/covjson 

[5]
https://ecmwf.adobeconnect.com/p6224btxzng/

[6]

https://www.ecmwf.int/sites/default/files/elibrary/2017/17149-building-rich-and-interactive-web-applications-coveragejson.pdf

 

Jon Blower | CTO, Institute
 for Environmental Analytics


 
Follow the IEA on Twitter
@env_analytics  and on LinkedIn

The Institute for Environmental Analytics (IEA)
 


Philip Lyle Building, University of Reading, Whiteknights Campus, Reading RG6 6BX
T: +44 (0)118 378 5213
M: +44 (0)7919 112687 


E: j.blo...@the-iea.org W: www.the-iea.org
 

From: 
CF-metadata  on behalf of David Johnson 
Date: Wednesday, 26 July 2017 02:01
To: Sean Arms 
Cc: "cf-metadata@cgd.ucar.edu" 
Subject: Re: [CF-metadata] JSON representation based on CF


 


Hi Sean, 

 


Thanks very much for that reference. CovJSON looks really good, and fairly mature. Pity we weren't aware of this and didn't check this out a couple of months ago!.


 


I think this would probably provide a full one-to-one mapping to CF-NetCDF, which I think some will want. And seems to cover all the needs we were trying to address with CF-JSON. And more besides.


 


Hopefully we will see widespread uptake and community acceptance. Getting into TDS would certainly be a step in the right direction.


 


This is good and exactly what these kinds of lists are for. And one less project to worry about. We will focus on our _javascript_ NetCDF reader instead:


www.github.com/metocean/netcdfjs


Unless of course somewhere is aware of another project dealing with that!


 


Cheers, Dave



 

On Wed, Jul 26, 2017 at 12:21 PM, Sean Arms  wrote:



Hello Dave,


 


I've been considering adding support for CoverageJSON to the TDS:


 


https://www.w3.org/TR/covjson-overview/


 


(Github page https://github.com/covjson/specification)


 


The spec specifically mentions CF-netCDF here:


 


https://www.w3.org/TR/covjson-overview/#netcdf


 


Cheers,


 


Sean





 


On Tue, Jul 25, 2017 at 1:20 PM David Johnson  wrote:








Hello All,


 


Apologies if this is wrong place to post this. But I would like to draw your attention to an open source initiative we have started:


cf-json.org.


 


The intention of this is to develop a standard around online exchange of climate and weather data. Based firmly on CF conventions for NetCDF. This was in response to the lack of any obvious standards for JSON. The transfer of weather data
 via RESTful services is now widespread and JSON is a common format for this. The geospatial community have geojson so we figured we need something similar. We are using this internally, but would be happy to see wider adoption. 


 


Pleased to 

Re: [CF-metadata] JSON representation based on CF

2017-07-26 Thread Mcgibbney, Lewis J (398M)
Hi Folks,
My colleague recently brought this list to my attention and I was very happy to 
see mention of CovJSON ☺
At NASA JPL’s PO.DAAC I have also been working with CovJSON manifestations of 
our data offerings. Specifically, I’ve been working with a bunch of others on 
the pycovjson [0] toolkit which really lowers the barrier to generation of 
CovJSON for our data holdings.
I’ve also been talking with Jim Gallagher and Nathan from OPeNDAP about porting 
the pycovjson logic to C++ and adding it as a data response handler within 
OPeNDAP.
Actually, today at the ESIP Summer Meeting, Jon Blower, Univ Reading, UK and I 
will be presenting on exactly this topic [1]. It would be great if folks could 
join us and we can further the discussion.
I know this message is pretty late, but the maling list conversation was only 
brought to my attention very last last night.
We are kicking off the Telecon in around 2 hours.
Lewis

[0] https://github.com/Reading-eScience-Centre/pycovjson
[1] http://sched.co/As6Y

Dr. Lewis John McGibbney Ph.D., B.Sc.
Data Scientist II
Computer Science for Data Intensive Applications Group (398M)
Instrument Software and Science Data Systems Section (398)
Jet Propulsion Laboratory
California Institute of Technology
4800 Oak Grove Drive
Pasadena, California 91109-8099
Mail Stop : 158-256C
Tel:  (+1) (818)-393-7402
Cell: (+1) (626)-487-3476
Fax:  (+1) (818)-393-1190
Email: lewis.j.mcgibb...@jpl.nasa.gov

   [cid:image001.png@01D305EC.39D6B730]

 Dare Mighty Things
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata