Add widgets to UI to control COLORSCALERANGE

[rsignell-usgs]

We decided on our initial call yesterday with Data61 that an appropriate first task for @jiwalker-usgs to attempt would be to add widgets to control COLORSCALERANGE so that TerriaJS could issue WMS requests like this:

http://ereeftds.bom.gov.au/ereefs/tds/wms/ereefs/mwq_gridAgg_P1A?LAYERS=Chl_MIM_mean&ELEVATION=0&TIME=2009-01-01T00%3A00%3A00.000Z&TRANSPARENT=true&STYLES=boxfill%2Frainbow&CRS=EPSG%3A4326&COLORSCALERANGE=0.1123%2C4.642&NUMCOLORBANDS=20&LOGSCALE=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&FORMAT=image%2Fpng&SRS=EPSG%3A4326&BBOX=147.47521484374,-28.598397216798,157.70881530761,-18.364796752931&WIDTH=256&HEIGHT=256

Right now there are no such controls:

One more wrinkle: these controls should only appear on WMS endpoints that support COLORSCALERANGE (e.g. ncWMS, sci-wms), but unfortunately I can't think of a good way to determine that. There is no mention of COLORSCALERANGE in the getCapabilities because COLORSCALERANGE is an extension, which isn't part of the WMS standard!

http://ereeftds.bom.gov.au/ereefs/tds/wms/ereefs/mwq_gridAgg_P1A?service=WMS&version=1.3.0&request=GetCapabilities

I can only think of a non-robust way to determine if the server is a ncWMS server, which would be to check the getCaps and see if there is style with name boxfill/occam, which exists in all ncWMS servers I've seen (since it's configured by default):

<Style>
<Name>boxfill/occam</Name>
<Title>boxfill/occam</Title>
<Abstract>boxfill style, using the occam palette</Abstract>
<LegendURL width="110" height="264">
<Format>image/png</Format>
<OnlineResource xlink:type="simple" xlink:href="http://ereeftds.bom.gov.au/ereefs/tds/wms/ereefs/mwq_gridAgg_P1A?REQUEST=GetLegendGraphic&LAYER=Chl_MIM_n_obs&PALETTE=occam"/>
</LegendURL>
</Style>

But this isn't robust because any other WMS service could also provide this style (though I haven't seen it).

I'll try asking the ncWMS mailing list if there is a better way...

@kring, what development branch should @jiwalker-usgs start with?

[ChrisBarker-NOAA]

these controls should only appear on WMS endpoints that support
COLORSCALERANGE (e.g. ncWMS, sci-wms), but unfortunately I can't think of
a good way to determine that. There is no mention of COLORSCALERANGE in
the getCapabilities because COLORSCALERANGE is an extension, which isn't
part of the WMS standard!

I have a hard time reading the standard, but GetCapabilities returns XML,
which is designed to let you add extra stuff that will be ignored be
services that don't know what do do with it, so COLORSCALERANGE and and
other extension could be added to the GetCapabilities response.

of course, ncWMS and sciWMS would need to actually implement that...

And if there is no way to enumerate extensions in a GetCapabilities
response, that's a big bug in the standard. (not that we can do anything
about that easily!)

The other option is to simply make a request with COLORSCALERANGE, and see
if it fails -- the "It's easier to ask forgiveness than permission"
principle.

[rsignell-usgs]

@ChrisBarker-NOAA, we could just specify the COLORSCALERANGE to every server, but servers can just ignore stuff they don't understand, so how would we know it failed?

[ChrisBarker-NOAA]

is that the way the protocol works? shows my ignorance. DAmn, that sucks, and seems really error prone to me: you can't get the full capabilities with GetCapabilities, and if you ask for something it doesn't do, it ignores it -- kind of untrackable.... :-)

-CHB

[jiwalker-usgs]

Are widgets required to be enabled by spec handshakes like this? Would it be possible to opt into this widget in the dataset json? I'm still getting up to speed on the way this configuration works, but an opt-in strategy seems reasonable for this type of thing.

[rsignell-usgs]

@jiwalker-usgs, you could do that, but we don't want to require dataset json. We want the user to be able to drag-and-drop a ncWMS endpoint and have the COLORSCALERANGE widget pop up on the control window for the dataset.

[kring]

@jiwalker-usgs you should work off the newui branches of TerriaJS and NationalMap.

My initial thought, like @jiwalker-usgs, was to put an option to control this in the init file. Obviously it's better if we can infer it automatically from GetCapabilities, if possible, but if that's not possible I don't think we have a better option than putting it in the init file.

[rsignell-usgs]

I'm now wondering whether we modify this first task, and have @kring or @stevage first add the COLORSCALERANGE UI widgets, and just have @jiwalker-usgs add an ELEVATION widget.

That way @jiwalker-usgs would have a very simple 1st task (the diffs to add the COLORSCALERANGE widgets should be a very good starting point for adding the ELEVATION widget).

What do folks think?

[kring]

@rsignell-usgs it's up to you and @jiwalker-usgs. We're happy to either guide Jordan in implementing it, or do it ourselves. Jordan, did you run into difficulties, are not sure where to begin, or just having trouble getting time away from other tasks to work on it?

[jiwalker-usgs]

@kring it is mostly the latter, though if there is good developer getting started guide you can point me to, it wouldn't go unused.

[rsignell-usgs]

@jiwalker-usgs and I met with @kring via gotomeeting last night, and decided that a first step in getting this going would be for Jordan to try adding the COLORSCALERANGE widgets.

There are existing tests to determine if we have a ESRI WMS service or a geoserver WMS service:
https://github.com/TerriaJS/terriajs/blob/newui/lib/Models/WebMapServiceCatalogItem.js#L346-L352

So first we need to check for ncWMS, raised as a separate issue here: #8.

[rsignell-usgs]

Fixed by TerriaJS/terriajs#1754

Example: https://gamone.whoi.edu/terriamap/#clean&proxy/_60s/https://raw.githubusercontent.com/USGS-CMG/terriajs-dive/master/examples/ec2015_power.json