Prioritized List for EDE v. 0.0.1

[cszc]

Quick list of what I think we need for a first version to show interviewees. I think some of these may have already been completed. We can discuss at the meeting if we need to add/take away anything.

Front End

First Priority

• [ ] Human Readable Labels for Datasets: Description and Summary. Have user input nice non-stupid title. Alison and Christine will seed first datasets with titles.
• [ ] Color Key: Explain what color gradient means
• [ ] Aggregating to Different Regions / Countries (GADM Level): Maybe priority if not too difficult

  Early Term

• [x] Pan
• [x] Zoom
• [ ] Formatted Metadata: Make Prettier
• [ ] Different Resolutions / Aggregating Spatially / Regridding

  Mid Term

• [ ] Search Function: Plus other ways of finding relevant data sets, i.e. top five, most recent per user, etc.

  Queries

  First Priority

• [ ] Histogram: Start with histogram of single point
• [ ] Trend Line

  Early Term

• [ ] Compare 2 Data Sets:

  Mid Term

• [ ] Histograms: Other histograms
• [ ] Aggregate by day, week, month, quarter, year: Pre-defined, part of query language
• [ ] Start Date/End Date:
• [ ] Summary Statistics:
• [ ] Average (Spatial and Temporal):
• [ ] Counts:

  Other:

  First Priority

• [ ] Non Agricultural Data Sets: :deciduous_tree: GSDE - Soil dataset; :partly_sunny: PRISM - Weather/Climate dataset; :cloud: AGMERRA - Climate Data

  Early Term

• [ ] Start Date/End Date

[cszc]

May 2, 2016 Priorities (After switching to Mongo)

• [x] @cszc - get reasonable labels from Josh
• [ ] @njmattes - color keys
• [x] @njmattes - panning, zooming
• [x] @ricardobarroslourenco - integrate gadm regions
• [ ] @ricardobarroslourenco - working on std dev, histogram, trend lines, point wise operations
• [x] @ricardobarroslourenco - spatial aggregations for mean, min, max
• [x] @ricardobarroslourenco - shape file to geojson for gadm regions or countries (existing regions) would be great if not too hard
• [ ] @njmattes figure out which portions of the interface that you have to have anyway (i.e. interface to choose multiple datasets)
• [ ] @njmattes comparing 2 data sets with operations/overlaying - maybe just division for round 1. needs additional visual representation.

[cszc]

What Labels Should Look Like

harms: damages (full harm model, business as usual) to plants (RCP 8.5) Climate Change Scenario/Forcing: RCP 8.5

WFDEI.CRU climate model: WATCH Forcing Data (WFD) by making use of the ERA-Interim

future: glossary

Final

Wheat_Anthesis_Model irrigation full_irrigation harms default climate_model wfdei.cru crop wheat ag_model papsim variable anthesis

Wheat_Biomass_Model irrigation full_irrigation harms default climate_model wfdei.cru crop wheat ag_model papsim variable biomass

Wheat_Yield_Model irrigation full_irrigation harms default climate_model wfdei.cru crop wheat ag_model papsim variable yield

Before (* denotes modified labels)

default_firr_aet_whe irrigation firr* harms default climate_model wfdei.cru crop whe* ag_model papsim `varaet default_firr_biom_whe* irrigationfirr\*harmsdefaultclimate_modelwfdei.crucropwhe\*ag_modelpapsimvar` biom default_firr_yield_whe irrigation firr* harms default climate_model wfdei.cru crop whe* ag_model papsim var* yield

@joshuaelliott We're trying to create more descriptive labels for these datasets for the front end. You can see how they show up here: http://atlas.obstructures.org/

I took my best guess at re-naming these. Do you have any suggestions? What is biom or aet? Is there a more descriptive label for papsim or wfdei? Also, I'm not sure what harms is referring to.

[joshuaelliott]

for this particular data, all this info is laid out in gory detail in the publication we wrote about GGCMI phase 1 protocols: http://www.geosci-model-dev.net/8/261/2015/gmd-8-261-2015.html

the irrigation dimension has 3 possible settings. in some files its just firr = fully irrigated noirr = no irrigation (can also call "rainfed") and in some files there is a 3 value call sum = the weighted average of irrigated and rainfed variables based on the area under each management condition in that grid cell or region.

the harms dimension is short for "harmonization settings" (see table 3 in the paper). this is a thing that we do when we're doing bug multi-model comparison projects to harmonize between different aspects of the models to make them more comparable. possible values here are default = default settings chosen by modeler (no harmonization) fullharm = fully harmonized on chosen input variables (in this case means planting dates, growing season length, fertilizer application rates, and atmospheric co2 concentration) harmnon = exactly the same as fullharm but using infinite fertilizer application rates (simulates variables without any nutrient stresses)

the climate_model dimension might be better labelled more generally as "climate_data" or something. in this case for example we are running with historical climate data so its not quite right to call it a "model" (though its also not quite wrong so whatever). there are lots of possible values in this case (see table 9 from the paper). again its probably not important to spell out the full name of the product, but i guess it would be good to get the capitalization right. WFDEI has 2 variants that we call WFDEI.CRU and WFDEI.GPCC. these are variants produced by the dataset provided and indicate that 2 different historical datasets were used in the bias-correction (CRU or GPCC). i doubt if you want to embed this in the metadata, but certainly we could have detailed descriptions somewhere and/or link to the paper.

for ag_models, see table 1 in the paper. its not really necessary to spell out the full name of the model or anything, but it might be good to get the capitalization right (for example, pAPSIM, pDSSAT, etc.).

var is variables, see table 4 in the paper. biom = total above ground biomass aet = actual evapotranspiration etc.

let me know if you have any more questions!

[ghost]

2 questions from me:

• are lat,lon,time,depth the only possible dimensions?
• do variables always only depend on (lat,lon), (time,lat,lon), (depth,lat,lon), or also on (time,depth,lat,lon) or others?

[joshuaelliott]

for the gridded data its always (time,lat,lon) or (depth,lat,lon) i think. the time dimension can be anything from day to year of course (and sometimes even "season"). all other dimensions are produced as different files.

in theory there are other possible dimensions for some datasets. but i think this is pretty safe for now. for seasonal climate forecast products for instance there are additional dimensions.

[ricardobarroslourenco]

@cszc I have been discussing with @njmattes about how to represent Agmerra. The resolution is really high in depth, and it is still unclear on how we would represent this on screen. This is something related with an aggregation in depth? Does it make sense to group/bin this dimension?

[joshuaelliott]

I don't think agmerra has depth. It has time though, is that what you mean? For a map visualization we probably want to provide various aggregation levels. Would be great if we could visualize daily, weekly, monthly, yearly, decafal, etc averages, and then have a time scroller to run through the data.

The other way we could do it is to have maps of monthly or annual or whatever temp and then have a daily time series plot come up if you click on a spot. Something like that.

For histograms we will definitely want to bin over time in most cases. Though obviosuly we have talked about binning over space and over both space and time as well.

On May 23, 2016 12:29 PM, "Ricardo Barros Lourenço" < notifications@github.com> wrote:

@cszc I have been discussing with @njmattes about how to represent Agmerra. The resolution is really high in depth, and it is still unclear on how we would represent this on screen. This is something related with an aggregation in depth? Does it make sense to group/bin this dimension?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub