Data Capture Event Export Questions

[philipbaileynar]

What to export?

• A single DCE at a time?
• User selected group of DCE?
• basemaps?
• What about analyses and summaries by mask?

Where to export?

• Let the user pick any folder they choose?
  • Remember last export folder
• Have a default exports folder inside the QRiS project structure?

Project Type?

• What is the appropriate project type? DataCaptureEvent or specific to the DCE being exported DamJamSurvey

Project Structure

• Do we need to use folders?
• Is outputs appropriate?

project.xml
outputs\
outputs\qris_dce.gpkg
basemaps\basemap01.tif
basemaps\basemap02.tif

[joewheaton]

Thanks @philipbaileynar for this. Some initial thoughts below:

What to export?

• A single DCE at a time?
• User selected group of DCE?
• basemaps?

I think you and I need a brainstroming session on this. I'm leaning towards making myThing (e.g. myBRAT, myDams, myRIM) projects to be exported at the grain of Methods from within DCEs to start. That keeps these projects lean, small and disposable. It also makes it easier for us to later import discrete projects and know exactly what they are and not have lots of choices to make. Instead, it is brining in one of these things at a time to a specific DCE under a specific (compatible) method.

I am thinking of how we make it easy for user to use "Collections" and "Add to Existing Collection" to "package" up things like:

• All the "Methods" in a single DCE
• A specific "Method" across multiple DCEs
• All the shit in my project.

I'm going to say no to basemaps for now, but yes to surfaces and what I am going to propose are Input Libraries. For example:

• MySurfaces
• MyAOIs
• MySampleFrames
• MyCenterlines
• MyCrossSections
• MyContext

The reason I'm thinking about this, is I don't really want people packaging all their inputs in one big mess, but like the idea of them having these discrete types (i.e. things we know how to handle on the other end if importing) and making it easy for them to put a bunch of these "projects" into a collection.

• What about analyses and summaries by mask?

We have not thought enough yet about what these are. Are they tables, figures, reports? Do they have GIS data? Of course we can handle riverscape projects without GIS Data. Do they need the context of every damn DCE they came from? Or just the context of the sample frame? I'm leaning towards the later.

If people really want to share the entire QRiS project... then zip it up and share it. I don't think we want to allow that (yet) in the warehouse. People will be greedy packrats. Make them be choosier (to start), then make them want something.

Where to export?

• Let the user pick any folder they choose?

Woaaa! You are not getting off that easy. These are exported (according to asking the user) to two places: a local folder and the Data Exchange. I'm fine with development step one just being local, but we are exporting to the Data Exchange. I imagine when we add the capability to upload to the warehouse, that we provide two options:

1. A checkbox to ALSO upload to warehouse (by default unchecked and greyed out if they are not logged in to Data Exchange via QRV)
2. Ability to upload an open project from QRV to warehouse. Project must be opened though so that we can do some checks that it works.

As to your question, lets not give them a choice. Lets keep a folder in the QRiS project folder for Project_Exports, lets have a standardized naming convention that includes a date-time suffix, and lets write these to disk.

I like your idea/insistence that these will be new geopackages and/or rasters exported staticly from the project. THEY NO LONGER will be linked into the QRiS geopackage.

• Remember last export folder

I need more info for what you mean by this? Maybe we:

• have a right-click menu option from the project to browse to exports folder? I don't know if we want to manage that in the project tree separately though (I don't think so)
• As part of the right-click Export as Riverscapes Project (only available on the nodes we determine or define), that dialog can include a log of exports and when. Since these will be static exports (not updating) some may use this as a way of cementing milestones. You could even allow them to open the export in Viewer - QRV, since we're connected. That would be really valueable as it would put it in its own place in the layer manager (not in QRiS tree) and open in QRV tree, and then people could inspect discrepancies between the current QRiS version of information, and an older export.

• Have a default exports folder inside the QRiS project structure?

You beat me to it! Yes please.

Project Type?

• What is the appropriate project type? DataCaptureEvent or specific to the DCE being exported DamJamSurvey

I am thinking MyDamJamSurvey. I am insistent on the 'My' because I want these project types to not get easily confused with our other project types.

No, I don't envision a DCE project type at this point in time (unless you want it to just mimic the tree of the DCE and be based on nested reference projects underneath it that must be created. As I said above, I am happy with using collections.

Project Structure

• Do we need to use folders?

Not necessarily. These 'my' projects will be pretty damn lean. I think for consistency with other stuff, we still keep the rasters outside of the geopackage as geotiffs, but everything else can go in a skimpy little geopackage.

• Is outputs appropriate?

Again, not necessary I don't think. We don't have inputs, intermediates and outputs. These are more discrete things.

project.xml
outputs\
outputs\qris_dce.gpkg
basemaps\basemap01.tif
basemaps\basemap02.tif

Or:

rs.project.xml
myBRAT.gpkg
rasters\LANDFIRE_EVT.tif
rasters\DEM_NED.tif