Problem at correcting complex confluences

[bwegsche]

Hi, I would like to transition from the STARS Arcmap toolbox to openSTARS and apply the workflow to a watershed in Canada. Deriving the stream network from the DEM works fine but when I try to correct complex confluences I get following error message (see bottom of the message). I`m not sure what the problem could be, it would be great if someone could point me in the right direction.

I use GRASS GIS 7.6 and R version 4.1.2

cp <- check_compl_confluences()

There are complex confluences in the stream network. Please run correct_compl_confluences() for correction

if (cp) correct_compl_confluences()

Fixing 21 complex confluences with 4 upstream segments each

Original stream topology file moved to 'streams_v_o4'.

Breaking lines and moving vertices ...

Updating topology ...

Fixing 4366 complex confluences with 3 upstream segments each

Error in system(syscmd, intern = intern, ignore.stderr = ignore.stderr, : 'CreateProcess' failed to run 'C:\PROGRA~1\GRASSG~1.6\bin\VEXTRA~1.EXE --overwrite --quiet input=streams_v output=complex_flows type=line where="stream in (51,76,99 ..........)

In addition: Warning messages:

1: In OGRSpatialRef(dsn, layer, morphFromESRI = morphFromESRI, dumpSRS = dumpSRS, :

Discarded datum unknown in Proj4 definition: +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.999912 +x_0=2500000 +y_0=7500000 +ellps=GRS80 +units=m +no_defs

2: In OGRSpatialRef(dsn, layer, morphFromESRI = morphFromESRI, dumpSRS = dumpSRS, :

Discarded datum unknown in Proj4 definition: +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.999912 +x_0=2500000 +y_0=7500000 +ellps=GRS80 +units=m +no_defs

Best, Bernhard

[MiKatt]

Dear Bernhard, would you please try the development version of openSTARS:

devtools::install_github("MiKatt/openSTARS", ref = "dev")

Please let me know if the problem persists. Best, Mira

[bwegsche]

Dear Mira,

I re-ran the correct confluences function using the development version of openSTARS and got now a different error message. See below the error message, I hope it is useful. Could it be the case that my DEM and river network is too complex for openSTARS? I`m running the code on the entire river network of the Saint John River watershed in Canada, which includes coastal areas and large wetland complexes.

Error in [.data.table(dt.streams, stream == dt.move_streams[jj, move_stream], :

RHS of assignment to existing column 'out_dist' is zero length but not NULL. If you intend to delete the column use NULL.

Otherwise, the RHS must have length > 0; e.g., NAinteger. If you are trying to change the column type to be an empty list column then, as with all column type changes, provide a full length RHS vector such as vector('list',nrow(DT)); i.e., 'plonk' in the new column.

Thank you for the help, Bernhard

[bwegsche]

I think I found an issue with my code. The derive_stream function includes an accumulation threshold that determines when a new stream gets initiated. I used the threshold from the tutorial in the supplementary information of the openSTARS paper but I think this might be set too low (accum threshold = 100). When I compare the original stream network with the derived one on a plot, I have way more derived streams which indicates that I set the accumulation threshold too low. When I compare the derived nework with a different threshold (default 700), it looks more reasonable. Is there a rule of thumb what accumulation threshold to chose , I guess it also depends on the resolution of the DEM? In my case the DEM has a resolution of 30*30m.

Cheers, Bernhard

[MiKatt]

Dear Bernhard, yes, using a small threshold results in a very fine stream network. And yes, this is related to the DEM resolution as the threshold gives the number of cells of flow accumulation when a new stream is started (see also r.stream.extract). A rule of thumb is difficult to give because it depends on the required stream resolution for the specific case. If your sampling sites are located at very small streams you might need a low accum_threshold (and a small min_stream_length). So it is always useful to have a closer look at the generated network. Additionally, when you run calc_sites() the sites are dragged to the closest stream and the maximum distance of this relocation is printed out. If this is too high, this may indicate that the network is not fine enough.

Nevertheless, the error messages you got are not very helpful and I will try to catch these issues somehow. Can you tell me how many stream segments you got originally and large your study area is?

[bwegsche]

Hi Mira,

sorry for the delayed response.

My derived stream network of the Saint John River watershed consists of 67125 features (stream segments). The main stem has a length of 673 km and the catchment drains an area of 55000 km2. Please let me know if this is useful or if you need further information.

In the meantime, I was able to run the entire workflow and the package was very useful. Thanks a lot for the help so far.

Cheers, Bernhard

[mattjbayly]

Note I got the same problem but fixed by increasing the min_stream_length & accum_threshold values in derive_streams().