Suggest either removing or changing the auto-fill of outputs in Stream Sinuosity and Planform Tool. At the moment it is currently filling out the 3 outputs (stream sinuosity, valley CL sinuosity, and planform polylines) as the same file name:

To create them as 3 separate polyline outputs with a desired naming scheme and file location, I edited to:

Use branchIDs I think?

Tested the Transfer Line Attributes tool for the Lolo watershed network from Jean's EP layer (“Lolo_NHD_FullExtent_20160906.shp”) to the NHDFlowline from the NHD website.

1. Generate New Lolo Network by running Transfer Line Attributes for Lolo network only.
   a. Clip NHD_Flowline to CHaMP watershed (Lolo) boundary; make sure to extent the most downstream segment out beyond the watershed as it is in Jean’s layer and in original NHDFlowline.
   i. Output: “NHDFlowline_20170502_Lolo”
   b. Run the TLA Tool.
   i. FROM: “Lolo_NHD_FullExtent_20160906.shp”
   ii. TO: “NHDFlowline_20170502_Lolo.shp”
   iii. OUTPUT: “Lolo_EPtoNHD_20170621”

2. Output sent as a feature class to a geodatabase.
   c. TLA Failure, with products created.

3. Examine the segments that did not join (received -9999 values)
   a. Seems that in all these areas Jean’s layer has segments split into multiple segments whereas the NHDFlowline has only one segment. Perhaps issue is that attribute values should be identical between these split segments, but in some cases CHINRATE and STHDRATE have different values between segments?
   i. This does not appear to be causing issues (when values are different in Jeans layer between segments that should be the same in NHD layer) based on other areas in the data where NHDFlowline had one segment and Jean's layer has multiple segments with slightly different attribute values (for non-essential fields)
   b. Only issue I can see is geometry is the same but segment lengths differ.
   i. Uncertain if failure message is related to this or not.

Data:
https://www.dropbox.com/s/qb9tl6oqrysr9r4/TLA_Issue_Lolo.zip?dl=0
Failure message:

Isn't there a standard name that's used for all projects?

There are two Output Workspace input parameter fields, and the Output Stream Network input parameter looks like a text block.

These tools are missing in the latest versions I have for GNAT: v 2.2.01_TEST and v 2.2

Ran a 1000m segmented network through the Build Network Topology Tool using GNAT version 2.1.06. It appears the networkVrtx table was still not generated (based on the dissolving in-memory data at the end); the Topology network "run 01" successfully generated as well as the Stream Network Table.

Currently the GNAT.pyt file has a lot of commented out modules import statements, and unused modules. Needs to be cleaned up.

All tools should be able to output to shapefiles or File GDB at the user's preference. This is a bit of a task. I have already encountered one issue (Sinuosity tool) where the difference between shp and fgdb caused an error (unrelated to know issues like field names, etc). We will need to push to make sure shapefiles are the primary input/output type as we convert to project based GNAT.

In cases where the "target" stream network has reaches/segments that do not exist in the "source" dataset, attribute values from connected, adjacent stream reaches are transferred over to the "target" network reaches. There are also incorrect values being transferred.

The current version of the Transfer Line Attributes requires a Branch ID field name as a parameter. This can be changed to an optional parameter.The results around tributaries will be much better, however, if the transfers are made branch to branch.

Remove the Stream Order attribute field from the stream branch output file.

GNAT version 2.1.06. I am unable to create a new GNAT Project using the "Create a New GNAT Project Tool". This is keeping me from being able to run segmentation of the stream network.

Small gaps (~20cm) in the network that are disconnected pass through the Network Errors tool without being detected.

Please see attached zip with:

1. Geodatabase: has the segmented (1000m) network for Lolo watershed. It was run twice through the Build Network Topology and Find Network Features tools (corresponds to run01 and run02 feature classes, respectively) and the Stream Network and Network Features tables and Network Vertex layer link to run02.
2. mxd: Has bookmarks corresponding to the locations of all the small gaps that were detected using the FLoWs tool in checking for compatibility of the network with HexSim.

Lolo.zip

Change the name of the Find Network Errors tool to something like Find Network Features.

Hi @volkcj & @KellyMWhitehead ,
I can hook up your subdomain on this. What do you want it called? Just gnat.riverscapes.xyz or something else?

Feature class is not generated in Build Network Topology Tool of the GNAT Toolbox (all versions)

There is a need to symbolize geomorphic attributes (i.e. sinousity, planform, threadedness, gradient) in the Riverscapes toolbar. To do that, whether or not these attributes were calculated for a segmented stream network should be stored in the project XML file.

This information can be stored as parameter nodes within the GNAT realization.

After Creating a new GNAT Project and Loading the Input Data Sets, when I select the Stream Network shapefile from the GNAT Riverscapes project folder, the drop-down is blank. It will work correctly and run through Segmentation; I just have to manually type in "ReachID" as the Unique ID field.

Data:
https://www.dropbox.com/home/Riverscapes_share/Lochsa_Data

(Original Stream Network used for the commitment is the run02 network from the Preprocess.gdb--all Riverscapes data is inside the GNAT Riverscapes folder)

So in this version of arcGNAT (2.2), it looks like Build Network Topology has gone back to writing the NetworkVrtx nodes out into a shapefile that goes into the Toolbox folder, rather than into the Preprocess geodatabase with the _run01 and Stream Network table output. Any way we can switch it back to writing it into the geodatabase? (It had been fixed several versions ago and was doing this correctly up to the last version I've been using, arcGNAT_2.1.12)

Thanks.

Xml files store segmented network path as Outputs\ [RealizationName] \Analyses\ [AnalysisName] \SegmentedNetwork.shp\SegmentedNetwork.shp

Though they are actually stored as: Outputs\ [RealizationName] \Analyses
[AnalysisName] \SegmentedNetwork.shp

Discovered this issue in version 2.3.1--unsure yet how many versions back this issue goes.

The stream confluence nodes are generated during the stream order calculation process.

(From Jean) The tool crashed when I made edits to the *_processed file and tried to re-run the Find Network Errors tool.

You must make edits to the original dataset, then rerun the Topology tool before you run the error tool again. It would be more convenient to be able to make edits to the *_processed file and be able to re run the error tool as you are working without having to go back to the topology tool. This would allow you to maintain a original dataset in case you make a mistake.

GNAT v 2.3.0 Step 3 > Stream Sinuosity and Planform Tool.
Only output generated is Valley Bottom Centerline with Sinuosity attribute. Missing the Segmented Network with Sinuosity and Segmented Network with Planform attributes.

There is an arcgis bug that is preventing shapefiles to work with the sinuosity tool.

Need to modify how the features are tracked without using OID/FID to remedy this.

Update sinousity and planform tool.

1. Does this need its own tool/project?
2. Part of Confinement tool?
3. Integrated Width also?

Both arcGNAT_2.1.01_050317 and arcGNAT_2.1.03_beta are having an issue where the repaired stream network will not load into the tool (as either a feature class or a shapefile) in the Stream Network Polyline Feature Class input.

Also I am not able to get anything to fill out under Output Segmented Line Network when I try to save the output (possibly due to the loading issue); it only allows me to try to save the output as a Geodatabase or a Basic Type, when I am trying to output a feature class into a new geodatabase.

There is currently a small bug in the Calculate Threadedness tool thich occurs when using "in_memory" for the temporary workspace. I think there is an issue with how the NODE_TYPE fields are being named when merging (see line 131).

The tool accepts three output names, but it only has two in the main function, which leads to the third output name overwriting the name of the scratch workplace. This breaks the program fairly quickly. While looking through GNAT.pyt, I saw that the text for properly passing on all variables was commented out. I'm not certain why they were commented out, but, after modifying it to only take two output files, I managed to get it to run properly. If you'd like, I can send you the code with the fixes that I made.

Encountered this error when recently testing out the Transfer Line Attribute table.

Messages
Executing: TransferLineAttributesTool C:\JL\Testing\GNAT\TransferLineAttributes\input.gdb\seg1000m_entiat C:\JL\Testing\GNAT\TransferLineAttributes\input.gdb\nhd100k_entiat LineOID C:\JL\Testing\GNAT\TransferLineAttributes\output.gdb\seg1000m_to_nhd100k C:\JL\Testing\GNAT\TransferLineAttributes\scratch.gdb
Start Time: Tue Jan 03 12:47:14 2017
Running script TransferLineAttributesTool...
GNAT TLA | Branch: 1

Traceback (most recent call last):
  File "<string>", line 353, in execute
  File "C:\dev\geomorphic-network-and-analysis-toolbox\TransferAttributesToLine.py", line 56, in main
    arcpy.Buffer_analysis(lyrToLineBranch,fcToLineBuffer,"10 Meters","FULL","ROUND","ALL")
  File "c:\program files (x86)\arcgis\desktop10.1\arcpy\arcpy\analysis.py", line 686, in Buffer
    raise e
ExecuteError: ERROR 999999: Error executing function.
An expected Field was not found or could not be retrieved properly.
An expected Field was not found or could not be retrieved properly. [nhd100k_entiat]
An expected Field was not found or could not be retrieved properly.
An expected Field was not found or could not be retrieved properly. [nhd100k_entiat]
An expected Field was not found or could not be retrieved properly.
An expected Field was not found or could not be retrieved properly. [nhd100k_entiat]
The table was not found. [GNAT_TLA_ToLineBuffer_1]
Failed to execute (Buffer).

Failed to execute (TransferLineAttributesTool).
Failed at Tue Jan 03 12:47:17 2017 (Elapsed Time: 3.00 seconds)

Use a slope raster to calc mean gradient per reach.

Ran Centerline Tool with GNAT v 2.1.12 with the following inputs and settings and received a blank centerline output. There were no error messages in the results messages. The Valley Bottom input was a single part, single feature. I've included the inputs (VB and stream network) and the output (blank Valley Bottom Centerline feature class) in the data below.

Data:
ValleyBottomCenterline.zip

The output feature class uses a less-than-ideal method for naming. Revise to use a better naming system ( add a simple suffix like "_run01", "_run02", etc.

Centerlines outputs are weird. I keep getting small loops, and that's it.

The Find Network Errors tool requires the network feature class that was output by the Build Network Topology tool (i.e. it has a "_processed" suffix). Currently if that feature class is not an input, it will cause an ugly error. But it should be handled a little more elegantly.

Proposed Structure for GNAT Project

If there are stream features in the "To" dataset that do not exist in the "From" dataset, all of the values in the "To" dataset have Nulls or zeros in the transferred attribute fields. These should instead all be something like -99999 for numeric fields, and "-99999" for string fields.

Currently the Calculate Stream Order tool still get's stuck in a loop when encountering some unknown issue with an input stream network. The tool either needs to be redesigned, or refactored to better pinpoint what is causing the looping error.

Steps: Went through the Build Stream Network and Find Network Features process once. Joined the table to the processed stream network layer, found and fixed errors, unjoined the table, then tried to rerun the process to check again for any residual errors. Build Stream Network worked this second time around to create a new stream network feature class with two timestamps, es expected. However, running the Find Network Features tool yielded this error and warning in the last lines of messages:

Error 000732 : Input features: Dataset C:\ISEMP\Networks\UpperSalmon_2Preprocess\Preprocess.gdb\UpperSalmon_EP_2017202_201702021559_201702060939 does not exist or is not supported.
Warning 000725: Output Layer: Dataset in network_fc_lyr already exists.
Failed to execute (MakeLayerFeature).
Failed to execute (FindNetworkFeaturesTool).

Support of working with multiple networks (disconnected) in one watershed.

Proposals

1. This could be accomplished through a NetworkID field with one INT per network.
2. A Network look up table could store the Downstream FID for each network, but must be careful of modified FID's during processing. Alternatively network could contain an IsOutlet or similarly named boolean field.
3. Downprocess tools would need to be modified to support the use of this enhancement, likely through a simple looping algorithm.

(From Jean) This tool worked well on the initial run for each network

However, when I ran the tool again after making edits based on the error report, I received an error. The solution was to delete the existing StreamNetworkTable then rerun.

It would be nice if the data in the StreamNetworkTable was overwritten or cleaned automatically out prior to each new run

Introduction

There is some discrepancy as to how GNAT should be using Analyses within the Riverscapes project. Specifically, GNAT tires to use analyses to store "Segmented Networks", where multiple versions of the same realization could be segmented at different intervals (or different segmentation parameters) (see Analyses section of: https://github.com/SouthForkResearch/gnat/wiki/GNAT_Project). The products of theses Analyses/Segmented Networks would serve as inputs to many other projects/tools.

Issues at Hand

1. Riverscapes does not support multiple versions of the same type of analysis. https://github.com/Riverscapes/Program/issues/4

2. @volkcj mentioned that we might add attributes to the segmented network, and keep this within the GNAT project. This would violate the uniqueness of the guid for the network dataset, and does not store that the attribute was added to the network within the project context.

3. Philip indicated that attribues should be added to the same line network (physical dataset?). The divergence of datasets created by capturing segmentation at the analysis level moves away from this.

Options/Proposals

While it did make some sense to store segmented networks at the analysis level, it is probably worth rethinking how the GNAT project is structured, at least the latter half. What we really need to think about is how GNAT is trying to keep the "family history" of the line network, and how each of the geomorphic attributes are related. In other words, what is GNAT trying to keep track of?

The Build Network Topology Table tool outputs a feature class with a "_processed" suffix. If this then later serves as input for the Topology Table, the ReachID field will cause a problem when rerunning the tool.

(From Jean) when testing out the Segmentation tool with 100 m segs with the "Divide remainder" option. There were some odd segments. For example, one segment was 0.18 m long while it's neighbor was 158.6 m long. The original segment was 158.8 m long. This issue did not appear at this particular segment when the remainder was at the top or when it was at the bottom of the segment

During a test run for the Walla Walla watershed, I tested the TLA Tool to have it transfer between the NHD EP Extent layer generated by Jean on 12/2/2016 to the NHD Flowline digitized 4/22/17 and then vice versa. Both are shapefiles projected into North America Albers Equal Area Conic.

In both tests (both directions), I had about 180/14,180 segments in the network fail to join and fail to have the attributes transfer. Aka attributes were not transferred (contain ‘null’ values), and there are null values in the output layer fields “Join_Count”, “TARGET_FID”, “JOIN_FID”, and “Shape_Length_1”. The attribute information from the original "TO" layer is retained, and the new “Shape_Length” field is filled out.

They formed an odd "cross" shape through the middle of the watershed. The data is present in the Dropbox folder below. The original layers used are
NHDFlowline: "NHDFlowline_copy.shp"
NHD_EPExtent: "WallaWalla_NHD_FullExtent_copy.shp"
Outputs: TransferLineAttributes.gdb > "WallaWalla_EPtoNHD", "WallaWalla_NHDtoEP"
https://www.dropbox.com/home/Transfer%20Line%20Attributes%20Tool%20QC

Build Topology Table ran on a HexSim network outside of Project mode successfully, but I couldn't find the processed shapefile that has IsBraided, ReachID, and IsHeadwater on it. Help?

I've gotten this 'failed to execute' result from all the segmentation runs I've done--here's a screenshot. It seems like it does segment and the script seems to go through until the end, but the failed to execute also appears.

I can provide the network tomorrow as well.

Add an option to add original steam network with attributes to the segmented output.

Currently the Build Network Topology Table and Find Network Errors tools output a copy of the input stream network dataset, with new fields ("IsHeadwater", "ReachID", "IsBraid") and the string "_processed" appended as a suffix to the file name.

However, if the processed output is then used as an input, the "_processed" suffix will be added to the file name again, resulting in a file with a name like "stream_network_processed_processed_processed_processed" after multiple runs of these tools. The suffix should also differentiate between output from the Build Network Topology Table and the Find Network Errors tools.