Show charts on feature info via the ncWMS2 GetTimeseries service

[RacingTadpole]

We now have charts which show data associated with a point or region over time, eg. power generation. The data for the chart is explicitly downloaded for each feature from a URL in the feature properties or template.

It would be great to extend this to:

1. Chart raster values at a point over time (eg. WMS).
2. Chart non-raster values at a point or region over time (eg. region x time csv data).

The first would require loading all the raster data for that point for all time (unless there is an alternative service that provides this, eg. THREDDS XML). The second is just a matter of slicing already-downloaded data along a different dimension.

Note (5 Aug 2016) - I've revised this issue to focus only on THREDDS servers, and opened #1921 to cover point 2.

[stevage]

Version 1 is required for NEII (https://github.com/TerriaJS/neii-viewer/issues/7)

[meh9]

@RacingTadpole, just to clarify, for case 1 where you say "raster values", do you mean load the actual image tile for the point and extract the pixel value that the user clicked on over time? GEOGLAM is another project that probably needs case 1.

[RacingTadpole]

Yes, that's what I was thinking @meh9 - unless there's a better way?

[stevage]

No need to load the actual tile, right? You can just generate a series of getfeatureinfo requests?

[meh9]

@RacingTadpole, well it depends on what you want. In most cases getting the "pixel value" of an image tile means that you are essentially extracting a colour - but unless you know the style that was used to colour that pixel from the source data you can't actually turn this back into a numerical value to put on a chart. There may be cases where we want to do something like that, but the most we could hope to do would be to draw the colours over time on the diagram.

@stevage's suggestion of generating a GetFeatureInfo request for each time instance would actually get you a numerical value you could graph, but would obviously be slow and resource hungry.

Since the NEII is deployed on THREDDS hooking into the THREDDS timeseries XML request is probably the way to go here in order to get something that works for now.

[stevage]

Yeah. We could look at doing the stream-of-getFeatureInfo version if we ever have a need for it.

[RacingTadpole]

Perfect, thanks for the clarifications.

[RacingTadpole]

Re THREDDS: Borrowing from the comments at https://github.com/TerriaJS/neii-viewer/issues/7, an example server is:

http://neii.bom.gov.au/services/solarclim

with getCapabilities for a layer at

http://neii.bom.gov.au/services/solarclim/wms/data/monClim_dirNorExp1Day.nc?service=WMS&version=1.3.0&request=GetCapabilities

The hint that this a THREDDS server is in the monClim_dirNorExp1Day.nc - it's an autogenerated WMS service from a NetCDF (.nc) file.

An example request to get time series data from 1993-01-16 to 1993-12-16 is here.

By changing x and y in this URL we get the nearest available data at that location. (It looks like that's relative to the bbox?)

When we add the above getCapabilities URL to NationalMap, we get a nice time-varying "mean direct normal exposure" layer across Australia. If you click on a point, you get the traditional feature info for the point:

The idea is we want to include a chart of exposure over time here, right?

So - how to implement this...? Here's one proposal:

• You need to explicitly include a <chart> tag in the featureInfoTemplate, with its long URL. Terria will need provide values for "bbox", "x" and "y".
• We update the <chart> tag to understand the xml format returned.

Potentially we could have WMS catalog items auto-detect if they're THREDDS and add the right <chart> tag to their feature info template, but I can't think how to make this work in practice.

Am I on the right track?

[meh9]

So, it's actually just a standard WMS GetFeatureInfo request with the time=1993-01-16T00:00:00.000Z/1993-12-16T00:00:00.000Z query parameter added, which is how the EPSG projection/BBOX/x,y is resolved. It would probably not be fun to have to recode that, but Cesium may have a thing you can use.

I know @AlexGilleran added some code to share/replay a GetFeatureInfo request, maybe it's possible to reuse some of that somehow.

[rsignell-usgs]

Getting time series plots from 4D datasets on THREDDS Data Servers (TDS) would be huge for our community. The question is which way is which type of data access is most effective.

For TDS endpoints, you can extract time series either using either a WMS query or a NetCDF Subset Service query. For example, this TDS dataset

http://thredds.ucar.edu/thredds/catalog/grib/FNMOC/WW3/Global_1p0deg/catalog.html?dataset=grib/FNMOC/WW3/Global_1p0deg/Best

You can use the WMS getFeatureInfo with info_format=text/xml, which uses X and Y screen coordinates, like this: http://thredds.ucar.edu/thredds/wms/grib/FNMOC/WW3/Global_1p0deg/Best?&LAYERS=sig_wav_ht_surface&ELEVATION=0&TIME=2016-11-15T00:00:00.000Z/2016-11-16T00:00:00.000Z&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-180%2C-140.625%2C180%2C140.625&X=431&Y=253&INFO_FORMAT=text/xml&QUERY_LAYERS=sig_wav_ht_surface&WIDTH=512&HEIGHT=400&url=http%3A%2F%2Fthredds.ucar.edu%2Fthredds%2Fwms%2Fgrib%2FFNMOC%2FWW3%2FGlobal_1p0deg%2FBest

or you can use the netCDF subset service, which uses lon/lat coordinates, like this: http://thredds.ucar.edu/thredds/ncss/grib/FNMOC/WW3/Global_1p0deg/Best?var=wnd_wav_ht_surface&latitude=-42.1&longitude=125.2&time_start=2016-11-03T00%3A00%3A00Z&time_end=2016-11-23T12%3A00%3A00Z&accept=xml

In the upcoming new TDS5.0 version, the ncWMS service has been replaced by ncWMS2, which has a special getTimeSeries WMS extension, so for the same dataset on TDS5.0, you can request:

http://geoport.whoi.edu/ncWMS2/wms?REQUEST=GetTimeseries&LAYERS=WW3-Global/sig_wav_ht_surface&QUERY_LAYERS=WW3-Global/sig_wav_ht_surface&BBOX=-180,-144,180,144&SRS=EPSG:4326&FEATURE_COUNT=5&HEIGHT=600&WIDTH=750&X=636&Y=378&STYLES=default/default&VERSION=1.1.1&TIME=2016-11-17T00:00:00.000Z/2016-11-23T00:00:00.000Z&INFO_FORMAT=text/csv

Which of these would be most desirable to use?
Perhaps the ncWMS/ncWMS2 extentions, since TerriaJS will already have the WMS endpoint?

[rsignell-usgs]

@guygriffiths, I have this correct, that ncWMS and ncWMS2 use different protocols for returning time series plots, right?

[guygriffiths]

Yes, that's correct. ncWMS used GetFeatureInfo, ncWMS2 uses GetTimeseries

[kring]

Here's an ncWMS2 server with GetTimeseries support. https://gamone.whoi.edu/ncWMS/wms?SERVICE=WMS&REQUEST=GetCapabilities&VERSION=1.3.0&DATASET=COAWST

[rsignell-usgs]

And here the very same dataset on a ncWMS server with GetFeatureInfo: http://geoport-dev.whoi.edu/thredds/wms/coawst_4/use/fmrc/coawst_4_use_best.ncd?service=WMS&version=1.3.0&request=GetCapabilities

[kring]

Cesium's UrlTemplateImageryProvider allows a pickFeaturesUrl to be specified using a templatized URL: https://cesiumjs.org/Cesium/Build/Documentation/UrlTemplateImageryProvider.html

• {z}: The level of the tile in the tiling scheme. Level zero is the root of the quadtree pyramid.
• {x}: The tile X coordinate in the tiling scheme, where 0 is the Westernmost tile.
• {y}: The tile Y coordinate in the tiling scheme, where 0 is the Northernmost tile.
• {s}: One of the available subdomains, used to overcome browser limits on the number of simultaneous requests per host.
• {reverseX}: The tile X coordinate in the tiling scheme, where 0 is the Easternmost tile.
• {reverseY}: The tile Y coordinate in the tiling scheme, where 0 is the Southernmost tile.
• {reverseZ}: The level of the tile in the tiling scheme, where level zero is the maximum level of the quadtree pyramid. In order to use reverseZ, maximumLevel must be defined.
• {westDegrees}: The Western edge of the tile in geodetic degrees.
• {southDegrees}: The Southern edge of the tile in geodetic degrees.
• {eastDegrees}`: The Eastern edge of the tile in geodetic degrees.
• `{northDegrees}: The Northern edge of the tile in geodetic degrees.
• {westProjected}: The Western edge of the tile in projected coordinates of the tiling scheme.
• {southProjected}: The Southern edge of the tile in projected coordinates of the tiling scheme.
• {eastProjected}: The Eastern edge of the tile in projected coordinates of the tiling scheme.
• {northProjected}: The Northern edge of the tile in projected coordinates of the tiling scheme.
• {width}: The width of each tile in pixels.
• {height}: The height of each tile in pixels.
• {i}: The pixel column (horizontal coordinate) of the picked position, where the Westernmost pixel is 0.
• {j}: The pixel row (vertical coordinate) of the picked position, where the Northernmost pixel is 0.
• {reverseI}: The pixel column (horizontal coordinate) of the picked position, where the Easternmost pixel is 0.
• {reverseJ}: The pixel row (vertical coordinate) of the picked position, where the Southernmost pixel is 0.
• {longitudeDegrees}: The longitude of the picked position in degrees.
• {latitudeDegrees}: The latitude of the picked position in degrees.
• {longitudeProjected}: The longitude of the picked position in the projected coordinates of the tiling scheme.
• {latitudeProjected}: The latitude of the picked position in the projected coordinates of the tiling scheme.
• {format}: The format in which to get feature information, as specified in the GetFeatureInfoFormat.

If we were to make all of these parameters available to feature info templates (plus a few more that Cesium doesn't deal with, like time, style, and dimension values), it would allow our users to embed a chart derived from the ncWMS2 GetTimeseries service on the feature info just by specifying the chart tag explicitly in a feature info template. GetTimeseries can return CSV directly, so there's no strict need even to support the XML format.

From there, it would be great to make this sort of chart the default behavior, given that TerriaJS already knows whether a particular WMS server it's talking to is ncWMS.