Collection 3 ARD Style Questions

[GypsyBojangles]

1. Should we ONLY display contiguous data for all C3 ARD styles? nbart_contiguity = true
2. Should indices be cloud masked? FMASK in ['valid', 'snow', 'water']
3. Should we include additional cloud masked styles for True and False colour? (and maybe more)
4. Should index style names be of the form: 'NDVI - Red, NIR' (current OWS behaviour) or 'Normalised Difference Vegetation Index' (current GSKY behaviour)
5. Should the "Red, Green, Blue" style be named "True colour" or "Simple RGB"?
6. Should the default Style be "True colour" or "False colour"
7. Do you prefer GSKY's presentation of NBART or OWS's? https://terria-cube.terria.io/#share=s-emivQTMBX4B6tLXXXWqnRST35uU (GSKY left, OWS right)

For reference:
https://explorer.dev.dea.ga.gov.au/products/ga_ls8c_ard_3
https://explorer.dev.dea.ga.gov.au/products/ga_ls7e_ard_3
https://explorer.dev.dea.ga.gov.au/products/ga_ls5t_ard_3

[robbibt]

Should we ONLY display contiguous data for all C3 ARD styles? nbart_contiguity = true

I think this makes sense, and should account for nodata as well as help clean up some of the ugly results you get near the edge of Landsat paths and rows. There are however issues with the current 20 m resolution Sentinel-2 contiguity bands not being fit-for-purpose for masking 10 m Sentinel-2 bands (I'm going to email this out more widely later this week), so there's a chance a different approach might be required for Sentinel-2 down the track.

Should indices be cloud masked? FMASK in ['valid', 'snow', 'water']

Yes. Cloud masking these indices would be a great improvement over the current approach with can lead to very misleading visualisations of the indices under cloud (e.g. the MNDWI water index which maps clouds as a strong water signal).

Should we include additional cloud masked styles for True and False colour? (and maybe more)

I think this would overcomplicate things - ideally we want to keep the number of options to a minimum where possible. Clouds in the True and False colour layers are easily recognizable visually unlike the indices where clouds can be very difficult to distinguish from non-cloud, so there's less of a pressing need to hide them from the user. This isn't a strong preference through, so happy to be overruled if anyone would like cloud-masked layers to be included.

Should index style names be of the form: 'NDVI - Red, NIR' (current OWS behaviour) or 'Normalised Difference Vegetation Index' (current GSKY behaviour)

I lean on the side of the GSKY behaviour here because it gives the user a lot more context; e.g. they might not know what "NDVI" is, but they will know they want a view of the data that focuses on "vegetation". That said, there are advantages in having the spectral bands info included too for indices like MNDWI/NDWI that vary by a single band. Would Normalised Difference Vegetation Index (Red, Nir) be too verbose?

Should the "Red, Green, Blue" style be named "True colour" or "Simple RGB"?

"True colour" and "False colour" feel more intuitive, use existing remote sensing terminology, and pair nicely together. I've never heard the term "Simple RGB" used outside of our web services, and there isn't really anything "simpler" about it vs. any of the other layers.

If we decided to include band names for the indices, it could be good to include them for these styles too, e.g. True colour (Red, Green, Blue)

Should the default Style be "True colour" or "False colour"

True colour. False colour is incredibly useful, but it raises the bar of interpretability significantly. I feel that users should be greeted with a view of satellite data they immediately recognise, then only be exposed to more complex remote sensing views once they make the choice to see them.

Do you prefer GSKY's presentation of NBART or OWS's? https://terria-cube.terria.io/#share=s-emivQTMBX4B6tLXXXWqnRST35uU (GSKY left, OWS right)

The OWS layer on the right is much more vibrant and dynamic - my preference would be for this one.

[SpacemanPaul]

My two bits:

1. In principle I agree. I agree with Robbit that the the contiguity bit on some products is unreliable to the point of uselessness - but assuming it's good on C3, let's do it for C3.

2. Yes - at least on indexes where that makes sense, which is most of them now I think about it a bit more.

3. That was how I wrote my original example configurations when OWS first rolled out - you'd need to revisit why they were removed in the first place. I'd be happy with that.

4. Robbi makes a good point. I would also say that OWS provides (or at least can provide) for each style, both a title (as shown above) AND a longer more detailed abstract. We could make better use of this, but Terria would need to come to the party and actually display it.

5. I like "True Colour". "Simple RGB" is hangover from my original example configs it was contrasted with "Enhanced RGB" where the blue channel was a blend of blue and coastal_aerosol. (Now I know a bit more about remote sensing and sensor wavelengths I can see why this was a pointless exercise.)

6. True Colour is the obvious default - for the reasons Robbi gave.

7. Robbi makes a good point, but for me the most striking difference is that the OWS version saturates so readily - most obviously in clouds, but also in deserts with high-albedo sand. I presume the difference is in the downscaling to 8 bits per channel. I think the sweet spot is probably somewhere in between.

[robbibt]

@SpacemanPaul Yep, I agree that for 7 something in between would probably be the best... split the difference?

(I did some notebook experimenting last year with visualising the layers after applying a log transform to dull down the high albedo areas and it seemed to work quite well too, but I have no idea if that's possible in OWS.)

[SpacemanPaul]

@SpacemanPaul Yep, I agree that for 7 something in between would probably be the best... split the difference?

(I did some notebook experimenting last year with visualising the layers after applying a log transform to dull down the high albedo areas and it seemed to work quite well too, but I have no idea if that's possible in OWS.)

It's totally possible!!! We do way weirder things to scale TMAD.

[GypsyBojangles]

As discussed in today's meeting @SpacemanPaul and @pindge, we would like to augment the behaviour of the following ARD C3 styles:

• For True Colour and False Colour styles, mask using ARD contiguity flag - oa_nbart_contiguity = True
• For indice styles NDVI, NDWI, MNDWI and NBAR, we want to mask with a combination of the oa_nbart_contiguity = True and oa_fmask in [1-valid, 4-snow, 5-water]