OK – this blog post comes from a backlog of questions and comments we receive from several facets of our work with lidar and DEMs and includes helping partners acquire data, working with data providers, as well as generating products for our use (e.g., sea level rise visualizations). In each case one of the stickiest aspects is not the lidar points, which are largely processed by machines, but the hydro-breaklines that are a human-derived product. Before we blame humans, however, I would argue that it is complex enough that machines cannot discriminate the nuances of determining water vs. land as well as we can; so until a breakthrough comes, it is up to us to generate them.
As an example, I consider breaklines as important (yeah I just said that) as the lidar data when generating DEMs for the Sea Level Rise and Coastal Flooding Impacts Viewer. Here’s why – the elevation data are provided with a known uncertainty/error that we can factor in (see the Uncertainty Tab); but the breakline error is not quantified (to a large degree) and can create errors in the range of meters not centimeters (i.e., 2 magnitudes more) where land is mistakenly forced to water via a breakline.
There are several techniques used to create breaklines, each with its pluses and minuses; however, I will leave that discussion to others. Instead, I am going to look at it from a user’s perspective. Typically with lidar, as opposed to photogrammetrically derived DEMs, the breaklines are used to denote the land-water interface for the purposes of hydro enforcement (making water flow downstream correctly) or hydro-flattening (making the water look like ‘water’) in DEMs as well as classifying points as water (chicken or the egg?).
As a recovering digitizer, I am aware of the challenges to being “on-your-game” and handling the data in a consistent yet detailed manner over large areas. I accept hydro-breakline errors/limitations; nonetheless, there are several issues that can crop up and should be assessed in relation to the user’s goals. Some of the more common issues are, in my own biased ranking of error potential:
- Lack of water feature coverage – streams or islands not break-lined
- Breaklines not following shorelines – poor(?) placement of line nodes
- Incorrect water elevations – the water surface floating above the land or dropping down to the water
- Connectivity of water bodies – streams not connected to water bodies
Every data set has its own set of underlying constraints (timing comes to mind) that will lead to a unique challenge in generating breaklines. To keep this installment short, I am going to cover only the first of the ‘Big 4.’ I will cover the other three in follow-on GeoZone post(s) and I am going to try to do all of them from one ‘scene’ (1:12,000 scale) in one data set.
Finding the four issues in fairly close proximity is actually pretty easy in coastal areas, which is something to keep in mind when looking at your data. The data set I am using is pretty old (pre 2004) so it came before the USGS specifications and I would expect it to have some warts. Nonetheless, it provides some good examples that are even valid in today’s lidar projects. Some of the issues may have (should have?) been caught in a more complete data review (qualitative review), some may not. Again, perfection is not an option – it is a shade of gray (not as in fifty however).
OK – so looking at the intensity (Figure 1) and aerial (Figure 2) images of our scene – it is about 4 square miles – with the as-delivered breaklines superimposed on both you can see the area has a mix of coastal habitats, and in this case, a pretty large tide range. Large tidal ranges make breaklining more difficult (the timing thing) so you kinda have to turn down the sensitivity knob a bit. As further evidence of the tidal variability, there is about one meter of tidal difference during collection (in a 4 square mile area; See GeoZone post on tidal collection) visible in the DEM before using the hydro breaklines (Figure 3).
Issue #1 – Lack of Water Feature Coverage
I have not mentioned the specifications part yet and it really is the driving factor – so let’s take a quick look at how the specs (mainly the USGS 1.0 spec) may cover this issue. The specifications on this point are upfront and pretty simple. There is a generally a stream size limit (e.g., 100 ft width), lake/pond size (2 acres), or an island size (1 acre) beyond which the breaklines are not collected. Seems fairly straight-forward; however, streams that change width, tidal streams or islands collected at varying tidal stages, and ponds that fluctuate can quickly make the specification pretty gray. And it can get a bit weirder if you are looking at consistency – since some features less than the specification get breaklined – and can be called out as not correctly breaklined.
With these basic specifications in mind, let’s look at our data. The example I chose (and there are a lot) is a common one in tidal areas and can really hinge on the exact timing of the collection. If we look at Figure 4 below, the breakline does not continue inland toward the yellow line. The yellow line is 99 ft so it seems like the breakline stops correctly where it is (100 ft limit) although it looks a little ‘incomplete.’ And that perception is correct – since the width of the breaklines are less than 100 ft for much of that ‘loop.’ In this case, one could argue that there should be no breaklines extending inland (no loop).
This breakline would look completely different if the tidal stage during collection was higher (Figure 5). In this case the entire area could be considered water and the little mounds could be viewed as ‘islands’ and not large enough to breakline – the result would be far different breakline placement that would look wrong at low tide. So, is there a ‘right’ or ‘wrong’? Well, yes and no – the width of the stream is defined when the data was flown and thus captured with the intensity (lidar and imagery are typically not collected at the same time) which can be difficult to interpret (Figure 6) and create inconsistency.
Final verdict on this seemingly simple issue (Figure 7) – I would ask the data supplier to breakline this stream, but they would be within the specifications if they said ‘no.’ This is why we, when making DEMs for SLR, have a 30 ft limit; it helps when dealing with connectivity, which is an important consideration for us. As a side note, I have only shown this one example; there are several similar issues in this one scene (Figure 1 and 2) – each could probably be argued both ways. And this is why it is important to include some funds for a QA contractor or 3rd party reviewer who can work as a mediator of these gray issues as well as a data supplier that has a reputation to uphold.
The next ‘Give Me a Break – Line’ GeoZone Post will address the other three big issues. If you have any comments or examples of breakline issues – please feel free to send them our way.