Open Hornbydd opened 6 years ago
Try the fluvial corridors tool, if Joe hasn’t mentioned it already. We tweaked their algorithm a bit and stuck it into the gnat tool, so I’m sure you could do something similar. If I remember correctly that centerline tool is sensitive in the headwaters and any odd geometry caused it to fail (overlapping/discontinuous valley bottoms, hydrography exiting the polygon, etc.) You can also pull/ review the code from gnat—the “utilities” version of the tool should work without being dependent on other nhd or gnat processing attributes.
Oh and all that is in reference to generating a centerline...
@dsear, @joewheaton and @volkcj ,
I have been exploring the Fluvial Corridors Tool (FCT), principally the Centreline Tool. It creates a centre line BUT there are many issue with it and I think are difficult to resolve in any sensible automated way...
So below is the output of the FCT tool when run on the EA floodzone map and OS Waterlayer network, the output being the black lines. Three important "gotchas" to observe:
Because of point 3 above such a dataset could not feed into any tool that would specifically process a river network, as they expect the data to conform to arc-node topology flowing in a source to sea direction.
But a network dataset deals with road networks and if you convert the centreline data from the FCT tool into a network dataset and MANUALLY place two "stops" one can pull out the shortest route, which in most cases is that centre line.
Zooming in, it looks great here:
But here the dark blue route has taken the shortest route (as that is what we have asked it to do) when it really should have followed the selected route.
So for one main river creating a centre line, converting it into a network dataset, making a human decision on where to manually place the "stops" can create a fairly descent centre line. But rivers are made up of many sub-catchments how would I distinguish the river of interest from all the other catchments and their floodplains?
I have also explored converting the centreline layer into a geometric network. This requires the network to have direction, typically the direction of the line, which in this case is useless. You can set a point dataset to be a sink/source but having played around with this loops come out indeterminate and influence any tracing functions.
So at the moment I am at a loss on how one could automate national scale processing and how we identify sources to start a search and pull out that centreline. Remember every spur is a source in the network. I'm sure one could prune back the network and remove most spurs but I think it would also have an affect on genuine river sources.
Also Floodzone map has some pretty nutty topological errors. Here is an example of the stream predominantly OUTSIDE it's flood zone!
@Hornbydd Nice work again, though the end result is disappointing. One observation is that the point on the Derwent where its not working (4th figure in your latest discussion) is the artificial cut through for the railway. You're not to know this but it's where Valley and Flood inundation layer are not morphologically the same. If you closed off the railway cut it would go around the bend OK. I wonder if for this Proof of Concept you go with the Manual approach to pull out "two stops" and run with this until there's a bit of time to consider how to do it automatically? Unless others have any suggestions? This would at least move you on to other components and give us the data we think is needed. So Force a Centre line through the network of the Derwent and the Kent - possible?
@dsear, - Agree, creating the centre line will allow me to continue with developing other tools. So I will pull out that centre line for the Derwent (and manually fix that bit where it followed a shorter route). I'll keep thinking of ideas on how to automate centre line extraction.
For example if you could attach Strahler order to the centre line network you could drop off all first order , but that would also prune back genuine sources. May be that is a hit worth taking as it would certainly kill off nearly all the problem spurs! BUT to assign order the network needs all the lines pointing in a consistent source-to-sea direction, which is not the case with the output from the FCT tool. I have developed a tool in RivEX that can traverse a network and flip polylines into their correct orientation with respects to a mouth node but this only works with single threaded networks and the output of FCT creates loops...
OK just a taster, I cleaned up the flood zone 2 data (merged adjacent polygons, removed small holes), ran that through the FCT tool and then using network analyst pulled out the centre line from the Thiessen network. Looks good!
I was wondering as we are trying to define the valley centre line may be I should drop ALL internal holes? This could potentially create an output without loops so polylines could be re-orientated? Not sure what the ramifications of dropping the holes are as they are obviously topographic highs in the floodplain?
@dsear and @joewheaton ,
What seem critical to computing some of the key metrics is generating that fabled dataset, the valley centre line! @dsear asked me to look into the VBET tool, to see if it could generate it. Below are some screen shots of it's output compared to the EA Floodzone map.
Limitations
I don't think this tool could be used to roll out national scale processing as each run of it needs to be fine tuned for the catchment size.
It does not actually create the valley centre line. Unless Joe has got some killer move up his sleeve I need to think on how to extract a valley centre line...