Project #1: Scoping and functionalities

[wetlandscapes]

I was thinking this might be a good place to put down ideas about the scope of the first project. More specifically, what do we want the output to do? And how do we work as a team to get that result?

I can think of some functionalities that would be of interest if we go the ShinyApp route, but I'll start with just one for now:

• If using ggplot, adding a "Download code" button would be neat. The intent of the button would be to copy server side code to a console of some kind (a pop-up window?) that users could then copy and paste to their own R session.
  • One option (may be too undeveloped): https://github.com/coolbutuseless/ggreverse
  • Depending on how the code is written, we could also convert code to a string object of some sort.
    • This could be a kind of fun exercise for anyone that wants to better understand non-standard evaluation (NSE), or the base equivalent.
    • More on NSE: https://cran.r-project.org/web/packages/lazyeval/vignettes/lazyeval.html

[wetlandscapes]

Another functionality: Generate different kinds of plots based on the entity type (e.g., dataTable, spatialRaster). For example, a dataTable entity could produce a x-y plot, while a spatialVector could be plotted on a map.

Something to think about, though, is the size of the files we could be plotting. That is, we may need to put a cap on the size of the files plotted, because outputs could take a long time to produce, or they could just choke the system.

An interactive form of map could be done using leaflet: https://rstudio.github.io/leaflet/

[wetlandscapes]

Another functionality: Plot units, where available. Because EML can include units, we can extract them from the attributes model and link them to a dataTable (for example). The units package includes a superset of units used by EML. Further, ggforce is units aware, and can be used with ggplot2 to automatically plot units included in a dataframe.

For more on using ggforce, units, and ggplot2: https://cran.r-project.org/web/packages/ggforce/vignettes/Visual_Guide.html#units

[clnsmth]

Scope: Interoperate with data repositories

Interoperate with data repositories to maximize the user base. Providing a service to one data repository may be unnecessarily limiting. Inputs to the app could be DataONE sources parsed with metajam.

NOTE: This scope is too broad for the code generation service offered for each data package in the EDI data portal (e.g. edi.4.4).

[atn38]

@clnsmth is the code generation service on EDI the same as PASTAprog?

Cool ideas so far @wetlandscapes! It'd be awesome if the output graphs/app is displayed nicely on the landing page for a data package, instead of being tucked away under the code generation options. That might mean a whole bunch of plots, so a good place to start as I said in zoom call is to plot measured variables spatially and temporally (so a heatmap of sorts and/or a time series for each measured variable). As we saw with the example dataset in zoom call, even detecting where dates and lat/lon info is stored in the data is not trivial.

[clnsmth]

Yes @atn38, that's the code generation service.

I like your suggestion for being able to integrate the app into web pages and data catalogs. Emphasizing modular design and interoperability with other systems will be key to keeping it's user base large.

[clnsmth]

Discussions about scoping and functionalities have moved to the project development site. I've added the request for integration with data catalogs to the project road map.