Input/Output data mapping tool

[BryonLewis]

Create a way to index inputs and outputs based on model conditions. You have several different model conditions and it picks datasets based on the combinations of the inputs.

I.E take the breakdown from https://en.wikipedia.org/wiki/Shared_Socioeconomic_Pathways

So it ingests all of the datasets and provides a tool for selecting the variables and displaying the proper layers from those sensors.

Layers have tags that can be associated with them, maybe from their parent datasets. These tags can then be used to apply a filter and load the layers that meet the filters.

I.E we have a filter mechanism where the user can select different key:tag pairs where data can be used to index different layers. and provide a list of data to load.

[BryonLewis]

Taken from John's Slack Post:

The filename tas_Amon_CESM2_ssp585_r11i1p1f1_gn_201501-206412.nc is a common format for climate model output files, particularly those following the CMIP (Coupled Model Intercomparison Project) conventions. Let's break down the sections:
tas: This stands for "surface air temperature." It indicates the variable stored in the file. Other common variables include pr (precipitation), psl (sea level pressure), and tos (sea surface temperature).
Amon: This signifies the time frequency of the data. Amon means monthly averages. Other possibilities include day (daily), 3hr (3-hourly), 6hr (6-hourly), monclim (monthly climatology), etc.
CESM2_: This identifies the climate model that produced the data. CESM2 is the Community Earth System Model version 2, developed by the National Center for Atmospheric Research (NCAR).
ssp585_: This indicates the scenario used for the climate simulation. ssp585 refers to the Shared Socioeconomic Pathway 5-8.5. This scenario represents a high-emission future with relatively little mitigation of greenhouse gas emissions. Other SSPs exist (e.g., ssp126, ssp245, ssp370).
r11i1p1f1_: This is the realization, initialization, physics, and forcing index. It's a way to distinguish between different runs of the same model with slightly different initial conditions or parameter settings.
r11: Realization 11. Different realizations represent different possible evolutions of the climate system given the same forcing scenario.
i1: Initialization 1. Refers to the method of initializing the model.
p1: Physics 1. Indicates a specific version of the model's physical parameterizations.
f1: Forcing 1. Specifies the forcing dataset used.
gn_: This denotes the grid type. gn usually signifies a native grid, which is the model's original grid resolution. Other possibilities might include gr (grid, regridded to a standard resolution).
201501-206412: This specifies the time period covered by the file. 201501 means January 2015, and 206412 means December 2064. The data in this file spans from January 2015 to December 2064.
.nc: This is the file extension, indicating that the file is in NetCDF (Network Common Data Format). NetCDF is a standard format for storing scientific data, particularly gridded data like climate model output. It's self-describing, meaning it contains metadata about the data it holds.

tas_Amon_CESM2_ssp585_r11i1p1f1_gn_201501-206412.nc
Our tags for the system could be "Variable""Frequency""ClimateModel""parameters""gridType"_"DateRange"

[BryonLewis]

Use Map Layer metadata field to implement a 'tags' object that would have something like vals: with 'DIVERS-H' in it, and a type: being 'input' or output'.
If would then have an object that represents 'filters': and each filter will have a key, a displayName, a description and a value/ value description.

On the client side there would be an interface to filter by Tags. This would list all layers with the specific Take vals contains 'DIVERS-H' and it will classify the layers at inputs or outputs.
There would be dropdowns for all the possible filter values and it would filter Map layers based on these filters.