Which GNAT Architecture is best?

[philipbaileynar]

There are two ways to structure the GNAT tool. Our goal is to balance building something reusable for attribute calculation (e.g. "I have a line network and I want to attribute it with just gradient") and the tool we really need for reach typing the Mississippi (i.e. that requires 10-20 attributes).

Option 1 - Standalone Scripts

The term GNAT refers to a loose collection of standalone tools that each calculates one or two attributes. For example we might have a single script that calculates gradient. And another that counts confluences/diffluences. What's important here is that these are standalone scripts that perform a single function. Each one can be run at the command line.

Advantages

1. Each script only needs to know about the inputs that it needs to perform its specific calculation. The confluences tool does not need a DEM raster for example. The tools can be streamlined to perform a single task. This makes them fast to write and run.
2. Easy to add more over time.

Disadvantages

We have three options for where to write the output of each attribute script and they all have downsides:

1. We write the output attributes back to the input feature class, which is a bad idea. We never change input layers as a matter of principle.
2. Each attribute becomes its own riverscapes project type which is unpractical for the two dozen or so attributes we need to support reach typing. It will consume all our time just to keep track of multiple copies of two dozen GNAT attribute projects for 2,000 HUCs in the Mississippi.
3. We have a "GNAT" project type and each tool appends the attribute that its responsible for to the output feature class in this project. This is problematic because it means a "partially complete" GNAT project that might have none, one, some or many GNAT attributes might be calculated at any one time. How do we track completeness or search for missing attributes that are buried in GeoPackage database columns?

Option 2 - GNAT "Tool"

GNAT is a single tool that performs a waterfall of operations. It takes a polyline network, sausage network and then a slew of contextual layers required to support the necessary attribute calculations. The "one tool" could calculate polyline attributes first, then any intermediate attributes (e.g. exploding the confluences into intermediate points layer) then summarize both the polyline attributes and intermediates onto the sausage network.

Advantages

1. Each step of the process is aware of all the other moving pieces. It becomes easy to pass the reach network to the confluence tool and then pass the confluence points to the "aggregator" that summarizes them for sausage polygon.
2. It guarantees that all attributes will be calculated. When a GNAT project is made available to another downstream tool, that tool knows that to expect inside the GNAT project.

Disadvantages

1. The GNAT command line will require lots of contextual layers that are only used by some of the attribute calculations. This makes the tool brittle. You can't run the tool unless you have all these contextual layers (unless we code clever, brittle code with if/else logic).
2. The GNAT tool becomes impractical for running just one of the tools (e.g. "I just want gradient").

FYI @joewheaton @lauren-herbine @MattReimer @KellyMWhitehead

[joewheaton]

Well... I'm a fan of Option 1, whereby we write each one to its "own" riverscape project of its "own" type. Lets not overblow the "spend all of our time managing all these". The reason to give ourselves options here is not because we're going to exercise them in the Mississippi. We will test each thing manually in a handful of basins → make an informed unilateral decision on what we want → run everywhere for 2000+ basins with consistent set of parameterization.
The reason to give ourselves the option of having these all broken out is the long-term utility (agility) of individual smaller projects to many, many, many people. What we will produce for own purposes will be something... it will be useful to some. However, if we think we're going to provide runs to people who pay for their own custom stuff, we invest in getting what we want via Option 1. I am sick of option 2. It is what we always do for expedience... and it always backfires.

With the project references now implemented and possible with the new metadata fixes, I see no reason to go to option 2.