<billroberts> hi everyone - I think it will be a small meeting today - lots of apologies. But will give people a few minutes to join the webex

<billroberts> Rob probably joining by IRC only, Jon might join for second half

<billroberts> scribe: maik

<billroberts> Proposed: approve minutes of last meeting https://www.w3.org/2016/06/01-sdwcov-minutes

<billroberts> +1

<Duo> +1

+1

RESOLUTION: minutes approved

<billroberts> https://www.w3.org/2015/spatial/wiki/Patent_Call

<billroberts> https://www.w3.org/2015/spatial/wiki/Meetings:Coverage-Telecon20160615

<billroberts> https://www.w3.org/2015/spatial/track/issues/18

<billroberts> requirement for 'model reuse' dropped

<billroberts> https://www.w3.org/2015/spatial/track/issues/19

<billroberts> agreement on issue 19 that the requirement is "to be able identify what type of coverage is being encoded "

billroberts: week before: how specific our solution should be
... grids most important
... but also time series
... and flexible for more arbitrary domains
... covers 3 concerns: subset spec, where metadata does, encoding

Duo: updates
... switch from previous dataset (set of geotiff tiles)
... to dggs (discrete global grid system)
... recursive resolutions (pyramid)
... our solution: pointcloud-type, all observations independent, no topology, but there are tiles which have an order between each other
... added graphs for timeseries
... not published yet, but in a few days

billroberts: how are range values encoded?

Duo: two types of values
... a) aggregate value, b) "zoomed" in
... essentially: an image

billroberts: geotiff as base64 encoded string, still like that?

Duo: yes

<billroberts> Maik: how are you encoding timeseries?

<billroberts> Duo: it's a timeseries of the single aggregated value per area/locatinon

<billroberts> Duo: it displays a plot of the aggregate values

<billroberts> scribe:billroberts

Maik: finished specifying and implementing tiling of ranges based on the index space

<Maik> http://reading-escience-centre.github.io/covjson-playground/

<Maik> examples -> Grid (tiled)

Maik: allow data to be stored not just in one tiled pattern, but possibly several different tiles, sliced in different ways
... eg tiled according to a bounding box and you get a time series of tiles of bounding boxes
... this allows generating static tiles that can be hosted cheaply
... a 'TiledNdArray' is a very generic data structure, not really tied to coverages
... it's not coordinates, it's just array indices
... that's probably the last major new feature to go n CoverageJSON before end of Melodies project

<scribe> scribe:maik

billroberts: scope of spec
... about 1 year to finish everything
... need to demonstrate some progress, a draft that can be reviewed and refined
... first public working draft soon after mid of Sep
... Maik, Jon, I will get tomorrow next month to start the process of writing the spec
... main components, how they relate to each other
... main part: how each part is specified
... JSON vs RDF vs mix, metadata vs data values ...
... using existing vocabs where we can
... have to make sure things are linkable (SDW req)
... parallels between two approaches
... handling of ranges, domain (though there are parallels)
... rdf data cube: domain info for each data point
... covjson: compact domain definition, not repeated for each point if possible
... (for grids most efficient)
... to what extend can JSON-LD help join the two views together, at least for domain, not really ranges

<billroberts> Maik: even for the domain, we hit restrictions of JSON-LD 1.0 because it doesn't allow idiomatic JSON structures

<billroberts> ...so sometimes want to step away from JSON-LD

<billroberts> ...but it works quite well for describing CRS, measured properties

<billroberts> ...it could work for specifying domains probably

<billroberts> ...But to have a good RDF representation of CoverageJSON, you would need a more complex pre-processor. JSON-LD itself is not a good enough match

<billroberts> ...so CRS, time parameters, measures and units are a good case for RDF

<billroberts> ...and how to deal with ranges? Duo's approach is also not doing pure RDF data cube, as the values are not simple numbers.

<billroberts> ,,, either a JSON array literal or a base64 encoded image are kind of equivalent - both need extra processing

billroberts: good case for highlevel metadata like in dcat etc., but not range in RDF, but where exactly do you draw the line

<billroberts> maik: a timeseries at a single point could easily be pure rdf data cube

<billroberts> ...and there could be multiple representations of a single coverage

<billroberts> ...how coudl they be linked together

Duo: we do timeseries entirely in RDF, each point own observation, independent

http://the-iea.github.io/ecem/

http://the-iea.github.io/ecem/app/data/ERA_Tmean_countries_sample.covjson

<billroberts> maik: has been developing something on another project, not MELODIES, where we have been using CoverageJSON for timeseries

<billroberts> https://json-stat.org/format/

<billroberts> some similarities between JSON-stat and CoverageJSON

<billroberts> maik: aware of it, also differences. JSON-stat is always a single file, can't link to external resources for definitions etc

<billroberts> ...it uses arrays for many things, so not suitable for including any JSON-LD

<billroberts> ...it misses a proper object structure or extensibility

billroberts: progress... I'll make contents list for what spec should contain
... take examples from other specs
... catch up with latest covjson stuff (tiling..)
... struggle how to turn discussions into actual agreements, things to decide, ...

<billroberts> maik: areas that are still open in Covjson - temporal reference systems (waiting for the Time subgroup to recommend something!); how to define different zoom levels on grids; how to link to different variants of a coverage in different CRS. Should that go into the main core format, or handle it by extensions to it.

<billroberts> ...already have a simple format for a collection of coverages. All coverages in it must have the same domain type

<billroberts> ...some formats have paging built into them. Covjson doesn't.

<billroberts> ...so a few things still to do but mostly details. Generally it works well

<Duo> +q

<billroberts> ...how do you decide complex parameters, for example 'air temperature at 2 metres height'

Duo: dggs defines zoom levels, up to single point value
... unifies coordinate systems

Maik: how does dggs solve plate movement problems (like lat/lon)

Duo: split up into polygons, then squares

Maik: are there clients that can handle it already?

Duo: yes, there's one called... [...]

<Duo> http://rhealpix.r-forge.r-project.org/

<Duo> paper on dggs: http://raichev.net/files/rhealpix_dggs_preprint.pdf

billroberts: come up with contents list until end of week

<billroberts> maik: concentrate on domain, range, parameters - don't get too involved in high level metadata

<billroberts> Yes, we can just refer to best practices from SDW or from DWBP for many of the high level things

<billroberts> maik: would prefer to use Github to author the spec document - better notifications etc

also for issue tracking etc

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: maik
Inferring ScribeNick: Maik
Found Scribe: billroberts
Inferring ScribeNick: billroberts
Found Scribe: maik
Inferring ScribeNick: Maik
Scribes: maik, billroberts
ScribeNicks: Maik, billroberts

WARNING: No "Topic:" lines found.

Present: Maik Duo

WARNING: Fewer than 3 people found for Present list!

Regrets: kerry jtandy scottsimmons edparsons

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 15 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/15-sdwcov-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report