The Problem
This problem has been discussed in the context of "project references" but is best summed up nicely in this logical question from Steve Bennett:
Hey Joe - loading up new GUT, Rave etc ... is there a reason why we can't have all the topography in a single project for each site just like GUT? Would make file management a bit easier and toggling between years. Just curious (you might have already told me about this
We have kept riverscape projects at "manageable" sizes (and I think are leaning towards doing more of this) mainly governed by download size (i.e. < 1.5 GB). I like the idea of projects being smaller unit chunks and they themselves repeat.
However the idea of a Project Collection might be worth exploring:
Examples Include
- All CHaMP Topo visits to a site in one "Collection" (leave the original topo projects alone), just collect them here.
- All GUT visits (i.e. with one topo... can have different realizations within representing different parametrizations or editing) packaged in one for a site (what we're currently doing)
- A Riverscapes Context, VBET, BRAT and RCAT project for a specific watershed.
- etc.
I think this is a different idea than a project reference. I think in a project reference, you bring across the one (or more) key layers that project needs as a depenency (e.g. A DEM) and typically as an input, and just mention that it came from this project if they want to dig deeper. This, by contrast, is just the original projects, and then a Collector project, that just opens up their own project business logic in Nodes underneath that collection. It is not a copy. It is the original project. Just a way of orgnizing them.
The Problem
This problem has been discussed in the context of "project references" but is best summed up nicely in this logical question from Steve Bennett:
We have kept riverscape projects at "manageable" sizes (and I think are leaning towards doing more of this) mainly governed by download size (i.e. < 1.5 GB). I like the idea of projects being smaller unit chunks and they themselves repeat.
However the idea of a Project Collection might be worth exploring:
Examples Include
I think this is a different idea than a project reference. I think in a project reference, you bring across the one (or more) key layers that project needs as a depenency (e.g. A DEM) and typically as an input, and just mention that it came from this project if they want to dig deeper. This, by contrast, is just the original projects, and then a Collector project, that just opens up their own project business logic in Nodes underneath that collection. It is not a copy. It is the original project. Just a way of orgnizing them.