Jump to content

Module04: which vertex of 1d_xs to snap to?

Recommended Posts

Hi, several questions thats confusing me

1) When digitising  1d_nwk_M04_channels_001_L.shp inbetween 1d_xs, does it matter which 1d_xs vertex we snap onto?

2) I digitised 1d_nwk_m04_channels_001_L.shp by following the gully of the creek. What happens if I dont follow the gully shape but I still snap onto the same 1d_xs vertex as if I were following the gully shape? i.e. Does tuflow consider the bends of the 1d_nwk_channel?

3) The 1d_xs_M04_Cxxx.csv files starts with x=0 z=41 to x=10 z=30 (say), how does TUFLOW know which gis vertex corresponds to x=0 z=41? Is it based on direction in which 1d_xs is drawn where the first gis vertex corresponds to x=0 and last gis vertex corresponds to x=10?

3a) What happens if total chainage of .csv (i.e. 10-0=10) dont equal length of gis line? how does TUFLOW know which gis vertex cooresponds to x=0 and x=10?

4) We will need THICK lines for 2d_bc_HX breakline. Where have we specified THICK in the 2d_bc_M04_HX_001_L breakline? Or is it automatically assumed THICK when using read gis z hx line max ==

5) CN line connects from the node of 1d_nwk_channel to the vertex of 2d_bc_hx. The CN line seems to overlap the 1d_xs line but not entirely. Does it matter which vertex on HX line the CN line connects to? 

much thanks


Share this post

Link to post
Share on other sites

Hi Jacky, answer to your questions below:

1. No it shouldn't matter as long as you are snapped to a vertices

2. TUFLOW does not take into consideration bends when modelling open channels in 1D. By definition, 1D solvers do not understand bends as it assumes water is always flowing downstream perpendicular to the cross section. If you have any tight bends in a 1D channel, you may want to consider manually adding additional energy loss to account for these features. A reason why you would want to follow the gully when digitising your 1d_nwk layer is a) your asking TUFLOW to automatically calculate the length of the channel b ) it's good practice from a QA side for model 'readability' i.e. someone looking at the model for the first time will get a better immediate understanding of what's being modelled. A series of cross sections with straight channels in-between may look to an outsider like your realigning the creek. One of the powerful features of TUFLOW is that it is built in a GIS environment where everything is spatially referenced. This allows for model layers to be drawn intuitively with respect to features such as the terrain and aerial imagery.

3. The 1d_xs.shp file is simply a reference to the CSV file, and is used by TUFLOW to determine which 1d_nwk channels use which cross section CSV files. Details such as vertices and line length do not need to align.

3a) see above

4. As per Table 7-5 in the TUFLOW Manual the datatype ZP used for the point file used in the command Read GIS Z HX Line Max == will adjust the cell elevation. This is the same as having a thick line. So Yes, it is automatically assumed THICK (THIN Z lines will adjust cell sides, not cell elevations)

5.Yes and No. Water levels are calculated at the start and end of 1d_nwk channels (this is at 1d_nwk nodes as TUFLOW will automatically insert a node at these locations if there isn't one already). The CN line is a connector that tells TUFLOW where this 1D node level connects with the 2D. Water level is interpolated along the HX line to the next time it's connected to a 1D node via a CN line. If the vertices are really close together then it may not matter which one the CN line is connected to. However, if you choose a location too far downstream or upstream from the 1D node to snap to, then you may get a discrepancy between 1D water levels and 2D water levels. Cross sections have no bearing on this connection.


Share this post

Link to post
Share on other sites

2) hm interestingly, I have noticed that how I digitise the channel in between 2 xs does affect the 2d dem check file in the end. Although it probably doesnt matter because that area gets code = 0 anyway. 

Share this post

Link to post
Share on other sites


I've just been reading through this thread and had a thought.

For point 3 if the 1d_xs line is simply a reference file, what does this mean for HX boundaries snapped to the end of the 1d_xs lines?

If the 1d_xs lines are for example too wide (but the referenced .csv files have the correct width) and HX lines are snapped to the 1d_xs; would water be entering the 2d domain the incorrect location? Should the HX lines be moved to the channel width represented in the .csv?



Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...