Elevation-derived Hydrography Acquisition Specs and READ Rules

Video Transcript
Download Video
Right-click and save to download

Detailed Description

National Hydrography Advisory Call:

This episode features speakers Christy-Ann Archuleta and Silvia Terziotti (USGS National Hydrography Team) who provide background information about the Elevation-Derived Hydrography Specifications and its companion document, The READ Rules (Representation, Extraction, Attribution and Delineation Rules).

Hydrography for the Nation:

High-quality hydrography data are critical to a broad range of government and private applications. Resource management, infrastructure planning, environmental monitoring, fisheries management, and disaster mitigation all depend on up-to-date, accurate, and high-quality hydrographic data. The U.S. Geological Survey National Geospatial Program National Hydrography Advisory Call has initiated a series of virtual seminars to highlight the uses of hydrographic data. These presentations are intended to share success stories from users who have solved real world problems using hydrography data, provide information about the National Hydrography Dataset and related products. The USGS manages surface water and hydrologic unit mapping for the Nation as geospatial datasets. These include the National Hydrography Dataset (NHD), Watershed Boundary Dataset (WBD), and NHDPlus High Resolution (NHDPlus HR). Hydrography data are integral to a myriad of mission critical activities undertaken and managed by government entities (Federal, State, regional, county, local, Tribal), nonprofit organizations, and private companies.

For more detailed information on national hydrography products visit https://usgs.gov/NHD


Date Taken:

Length: 00:34:48

Location Taken: Reston, VA, US


Al Rea: Hi, everybody. This is Al Rea, and this is the USGS Hydrography Advisory call, and we're still getting a few beeps coming in, so I think I'll wait just a minute or two more before we get started. I am recording this webinar in case you miss some of it or know somebody who does miss it. Just shoot us an e-mail, and we can shoot you a link to it. Again, we'll wait just 1 more minute. Okay. It sounds like we've got most people on that we're going to get. So we'll go ahead and get started. Again, this is the USGS Hydrography Advisory call. I'm Al Rea. Oops, sorry. I'm going to have to mute all. Okay, so today we've got two speakers. It's Christy-Ann Archuleta and Silvia Terziotti, and they have quite a lengthy presentation to give today. So we'll go ahead and let them get started, and I believe ... Christy-Ann, are you going to take it from the start?
Christy-Ann ArchuletaYes, I am. Can you hear me okay?
Al Rea: Yeah, we can.
Christy-Ann Archuleta: Okay.
Al Rea: Can you just introduce yourselves? And then when Silvia gets on, she can introduce herself, too.
Christy-Ann ArchuletaOkay. Well, thanks again, Al, and I'm Christy-Ann Archuleta, and I'm going to be presenting with Silvia Terziotti, who you'll hear from a little bit later, and today we'd like to share information about the Elevation-Derived Hydrography Specifications and its companion document, The READ Rules, which will be published very soon. So today we'll be giving some background information about this work, then a quick summary about the specifications themselves and the companion document, which that stands for Representation, Extraction, Attribution and Delineation Rules. So you can see why we call it the READ Rules for short, and then we'll talk about our next steps that are planned for implementation. So the importance of topography has been well-known and established for over 130 years. The USGS topographic quad sheet has been the standard for contour maps worldwide for decades. While the form of topographic data and the methods of collection have changed remarkably with the digital age, the basic uses and significance of the data remains unchanged. The USGS manages surface water and hydrologic unit to spatial data for the nation in the form of the National Hydrography Dataset, the Watershed Boundary Dataset and the NHDPlus High Resolution Dataset. Hydrography has progressed from blue lines on maps to a complex geospatial framework used for modeling, navigation and mapping. The 3D Elevation Program and the Hydrography Program are two of the core data programs for the USGS. When the USGS began creating topographic maps over a century ago, both hydrography and elevation were captured together, but in the 1970s ...
Al ReaChristy-Ann?
Christy-Ann ArchuletaYes?
Al ReaHi, sorry. There's some more background noise. I'm going to mute all again, and then you'll have to unmute yourself.
Christy-Ann ArchuletaOkay.
Al ReaOkay. I muted all. Now go ahead and unmute.
Christy-Ann ArchuletaCan you hear me?
Al ReaYeah, yeah, that's better. Thanks.
Christy-Ann ArchuletaSure. So in the 1970s as computer processing of map data became more prevalent, the two data sets were stored in different resolutions and formats and were collected by different USGS programs and were no longer well-integrated. The USGS is currently implementing methods to reintegrate the two data sets. Another opportunity for better integrated elevation and topography data is to take advantage of recent interest by the water community in collecting hydrography data from elevation. There are increasing numbers of users, and they're creating local resolution stream data from lidar-derived DEMs. They're doing this on their own, and these data are not always integrated back into the NHD. The water science community inside and outside of the USGS are dependent on both the elevation data and the NHD to satisfy their missions. So ideally hydrography would be collected with a lidar project, enabling the generation of both hydro-enforced, which is hydrologic, and hydroflattened, which are topographic DEMs, as well as providing a base for creation of NHD at local resolution. The importance of integrating our hydrologic stream and elevation data sets can be seen by looking at some of the issues caused by misalignment such as perpetuation of errors in alignment in the streams data, not capturing any recent changes in stream channels, not capturing headwater, intermittent or ephemeral streams not already included in the High-Resolution NHD, misalignment with imagery or other newer geospatial resources, and then there are the cascading effects in derivative products such as watersheds we create and the stream lengths, slopes and so on. Lidar data allows for the collection of previously unimaginable levels of detail and accuracy in topography, but it is different in character from traditionally produced elevation data. In spite of lidar's extreme detail, the point cloud requires supplemental breaklines in order to produce elevation surfaces that meet users' expectations and needs. Breaklines are used to define and control surface behavior of the DEM, such as the smoothness and continuity of it. The most striking need for this type of supplemental line work is when it's used to define the boundaries of water bodies and impose a familiar appearance and behavior to the water surface, such as making a lake or pond have a smooth cartographically pleasing surface. USGS now requires collection of a minimum set of hydrographic breaklines, which are needed to meet this need for all lidar data collection. Additionally, breaklines may be obtained for special projects such as for hydro-enforcement, and in this example that I'm showing, I'm going to show you the lines that were created for this type of purpose so just going to move on to the next ... This example shows how the double-line-stream boundary was used to flatten the appearance of this river, so you can see in it how it has sort of a bumpy surface when it's taken directly from the lidar, but with the collection of these breaklines, they can do treatments that make it have this very nice, smooth surface that we expect to see on our cartography product. The double line streams, the lake ponds, they're the only hydrographic breaklines that are required for collection by the 3D Elevation Program. In this next example, you can see how additional hydrographic features can provide a basis for hydro-enforcement of a DEM. The additional features that were added here are the streams, the culverts and an artificial path down there. With the collection of not only the minimum set of required features for hydro-flattening DEMs but also the collection of additional features that are needed for NHD when they're collected simultaneously with the acquisition of the lidar data, the hydrography and elevation data provided by the USGS can once again become integrated, and sorry for not moving through this animation very well, but here in this last ... you can see the hydroenforced surface where this culvert has been cut through a road to allow the water to flow across into this other water feature. So the integration of hydrography and elevation data is part of the current strategies to meet the vision of the USGS. We will be focusing on one aspect of this vision, strategy three, which is integrating 3DEP elevation data with NHD to create 3D NHD. And as a brief background to this decision, there are two major studies that identify the importance of integration of elevation and hydrography. There was the NEEA study, which surveyed Federal, State and local elevation users and found that there was a major need for horizontal and vertical integration of hydrography and elevation, and more recently, the HRBS surveyed the hydrography community ...
background noiseEnter your access code.
Christy-Ann Archuleta... [Indistinct] finding a strong need for horizontal and vertical integration of the two data sets.
background noiseEnter your [Indistinct] ID number followed by [Indistinct].
Al ReaChristy-Ann, let me mute all again.
Christy-Ann ArchuletaOkay.
Al ReaGo ahead, Christy-Ann.
Christy-Ann ArchuletaThe first step to meet that goal is the creation of the NHDPlus High Resolution Dataset that takes the best available NHD and elevation data and creates a nationally integrated data set. USGS recognizes that the NHDPlus High Resolution does not fully meet the goal of a well-integrated elevation and hydrography product. Elevation in the 3D Elevation Program, and NHD are not a good match in many places. The 3DEP elevation is based on lidar data currently, and the NHD is still mostly a 1:24K scale product that does not align well with the lidar surfaces. Burning the lower-resolution hydrography product into the higher-resolution elevation causes issues alignment and hydroenforcement. Unfortunately, this discrepancy has led many users to create hydrography that matches the elevation surface deriving it directly from the lidar surfaces on their own outside of using an NHD product. These lines may be a better match, but they often do not make it back into the NHD or meet the NHD requirements for topology or network connectivity. So this leads to the current efforts for this project. Our goal is to create hydrographic features that are horizontally and vertically integrated with a 3DEP bare earth Digital Elevation Model. We want the streams to match the lidar elevation surface. There are three main products that the hydrography product can be used for. It can be used for breaklines. It can be used for processing pre-conflation of features into the National Hydrography Dataset into NHD, and it can also be used in modeling for hydro-enforcement of digital elevation models. So the two documents that we're getting ready to publish in order to meet those goals again are the Elevation-Derived Hydrography Acquisition Specifications and the READ Rules. The specifications that we pulled together have been written to support and expand on two existing requirements that were set in place years ago. The NHD requirements, the NHD has widespread use nationally, and we want to produce data that can be converted to full NHD products. Currently, we're not including the WBD in the specifications, but we're hoping to do that in future revisions. And the Lidar Base Specification, we're creating a product that will be integrated with the bare-earth DEM and as defined within that specification. We also want to make sure elevation-derived hydrography specification meets the hydro-flattening requirements of the lidar-based specification. So now I'm going to pass it over to Silvia, who will talk about the specifications.
Silvia TerziottiAm I unmuted now?
Silvia TerziottiOkay. Great. Hi. This is Silvia Terziotti. I am going to just briefly talk about each one of these categories that are included within the specification and just briefly go through those. So our first section within the specification is how we define our collection area, and we're trying to support two types of collections, those that are done concurrent with lidar collection, so those would be defined by the Defined Project Area, or the DPA, and those that are done using existing 3DEP elevation products or holdings, and for both of these collection types, NHD has a minimum size requirement that the data be collected at a HUC10 level, so both of those would also require that HUC10 level of minimum mapping area, and also, any data that spans the complete HUC10 should have complete network connectivity. For concurrent collection since they're not always done on a HUC basis, the hydrography should be delineated for the entire DPA up to the boundary of the DPA. It should also be edge matched if existing lidar derived hydrography exists adjacent to the DPA. Otherwise, those sections outside of a HUC10 would need to be processed later on when adjacent areas are completed. Okay. We also specify what types of features should be collected. Because the hydrography is being collected primarily from elevation sources, there's a limited amount of information that we can get from derived features, so by necessity, we needed to parse down the types of features that are required for collection. You may recognize the FCodes we use match the FCodes in NHD, and the features are defined in the same way as the NHD for the most part. There are also codes for elevation and hydrography treatments in the F class and the E class, and each of these features is fully described within the READ Rules as well. There are additional fields that describe source data, methods, a user code and a comment field. In particular, the user code could be used when features outside of the specification are collected for project-specific needs but that we don't necessarily want to conflate to NHD. The user code can also be used to store more detailed FCode information that is known since the FCodes in the EDH are fairly minimal. So these features also must meet the 3DEP breakline requirements, and so the features that you see in the table on the right are those needed for hydro-flattening a DEM surface to meet the lidar-based specification. Okay. So we have a minimum delineation set of features. We define them as the minimum set of features comparable to the density of what is currently in the High-Resolution NHD Data, so using the NHD as a guide, feature alignment must match the bare-earth 3DEP DEM horizontally and vertically, so a Z-value has to be placed on every vertex. Features no longer present in the lidar surface should be removed, and features that need the READ Rules that were not present in the NHD can also be added to meet this minimum set of features. And then additional features, obviously if you've got a lidar surface, you can collect a lot more than what you currently have within the lidar, so to try and avoid overmapping additional features above the minimum set of features must also meet the requirements that a feature must be visible on the DEM, or that looks like it got ... Sorry, the wording is off or disappeared off the slide, but a feature must be visible on the DEM, or if it's not visible on the DEM, it should be present in accepted ancillary data sources, or if it's not visible on the DEM or in ancillary data sources, it can be collected if it's necessary to connect the hydrologic network, that is, if it's not a valid isolated network. The methods used to define how feature extents were derived should be identified in our methods field and in the metadata. That can be how the line work was generated. Was it created with a model or based on other sources? The features should also be compared to 3DEP bare-earth elevation surface so that will check the accuracy of the method used, and features should be treated with one of the [Indistinct] described in the [Indistinct]. And if the [Indistinct] method is not able to identify a feature type but the features appears to be there, the drainageway code can be used for features [Indistinct] distinction. [Indistinct]. So in defining our features, we have a few special cases. The first special case we'll go through is the HUC12 consistency. Many of you are familiar with the problems of NHD density issues that occur between the [Indistinct] quadrangles when the NHD was first digitized, so in this first slide, you can see that the quad lines and the areas highlighted in yellow are less dense network or line work than the surrounding quads, and then, even without the yellow, you can still see the difference, and then go back or next one.
Christy-Ann Archuleta Sorry.
Christy-Ann ArchuletaSorry. The [Indistinct] try to get to the yellow one.
Silvia TerziottiOh.
Christy-Ann ArchuletaOh, so the yellow is showing up on my slide, but it doesn't show up on the ...
Christy-Ann ArchuletaAh, that's okay.
Christy-Ann ArchuletaYeah, I'm not sure what's happening.
Silvia TerziottiYeah. We just keep going through. We'll see ... You can still focus on those lines, and you'll see that each one ... Each time we click through, you can see that there's a definite discrepancy between areas, and finally we'll hone in on a 12-digit HUC, and that 12-digit HUC shows a clear discrepancy ... Go ahead to the next one. Shows a clear discrepancy between the northern and southern section of the watershed. Our HUC12 consistency guidelines require that the line work is consistent throughout a HUC12, so the area in the southern portion of the water shed needs to be densified to match the northern section unless there are true geologic or land use or other reasons that the density should not be the same so just using the HUC12 to kind of densify the network. Culverts are a special case that we describe. As mentioned at the beginning of the presentation, one of the goals of these specifications is to create a hydro data set that's suitable to create a hydro-enforcement of the elevation surfaces, so identification of culverts is key to that goal. In lidar surfaces, transportation is probably the most common surface feature that artificially blocks the flow across a DEM, so we're trying to identify those areas and require the culverts and small bridges that weren't removed for the lidar base specification requirements are identified as culverts. Because the culverts are not currently NHD feature types, we treat them a little bit differently than other feature types, and we have a number of rules and priorities of how to code them, which I'll show in this next slide. The second ... READ Rules outline rules for coding a culvert so it's done consistently based on upstream and downstream features. This ensures that the culvert can be identified and extracted as an event and that the flow lines can be the merged based on the NHD FCode. The ... Just as a note, the HSRB has approved converting the culverts into event tables for use in the NHD, so hopefully that information won't be lost within the NHD. The next special case is a drainageway. The drainageway features a new NHD feature type that's used when further research is needed to either determine the true feature type or to determine whether or not it's actually a true hydrography feature and whether it should be included in the NHD. Many headwaters derived from lidar may be drainageway features or flow baths that have no clearly defined channel can also be coded as drainageways. Here is an example of what might be identified as a drainageway. There are no clear flow paths in the main valley there in that circle, but there's a clear channelized segment in the hillside and clear channels leading down to the main branch. The connecting features could be drainageway features because they may need further refinement and alignment to define their true channel there. Okay. Another [Indistinct] the hydro-enforcement at road intersections, headwater roads, roads at headwater areas of a watershed can greatly alter the flow of water and how watershed boundaries are derived, and we're requiring that any stream feature that ends within 100 feet of a road be examined to see if it should extend through the road feature. In this example here, there's three cases. The one on the left has used the NHD in blue, and the red line is the lidar-derived stream to delineate the stream segment across the road, and we would require a culvert be placed there, but the stream itself is correctly delineated. The middle stream stops 90 feet from the road with a clear culvert in the surface and a channel on the other side of the road, so it actually should be extended to the other side of the road and a culvert placed over that road section. And then the stream on the right ends 60 feet from the road but doesn't have as obvious a channel on the other side of that road, so ancillary data could be used through the best judgment of the person delineating the features to determine whether or not it should be extended. And then our last special case is the canals and ditches. Canals and ditches can create a great deal of complexity for networks but then connectivity and navigation and can range from large main canals to the small ditches that run in front of people's houses. There are many specific cases where a project might need a higher density of these types of features in their data set, but for elevation-derived hydrography, we require collection only if a canal is named, if it's greater than or equal to 300 meters long along its longest axis or if it's necessary to provide network connectivity. In general, canals and ditches that are in agricultural fields or in private property should not be collected, and if the project ... But if the project has a special need for those canals and ditches, then it can be accommodated using the user code, and that would allow the NHD to exclude them preconflation. So this is just an example of the NHD High-Res showing where the canals and ditch features are, and here you see the elevation-derived hydrography capturing the same canals as the NHD so preserves that resolution but corrects the geometry, and then, in this image, you see how many additional canals and ditches could be captured for elevation-derived hydrography that would greatly increase the density from the original NHD, and those are in magenta there. And then, in here, we just show where some of those decisions might be about whether or not that should be kept within the NHD, and then we're trying to extend the stream network or defined connectivity within the network, so some of these newer canal features that are very small going through the agricultural fields may not be necessary for NHD, so they can be captured and coded with a user code rather than an FCode to make them easy to exclude when conflating to the NHD but still be retained for your individual project needs. Topology, as part of the specification, we provide some basic topology rules and requirements, and we provide rules for ensuring the network has a continuous flow without breaks and is preconflation-ready or as close as it can be. We have alignment requirements. All features must align with a DEM and a current NHD where appropriate although we don't want correctly placed geometry from lidar-derived sources to snap incorrectly to older features, but all features must have downstream orientation. They must match between project areas, be logically and spatially consistent within the elevation data, both horizontally and vertically. The specifications also require that the collected EDH is tested for correct vertical and horizontal alignment against the DEM it was acquired from. All vertical lines and water-surface edges must be at or below the immediately surrounding terrain within 1 meter of the location of the DEM. Horizontal streams and other linear features must stay within their apparent channels. Polygon features should match the apparent boundary on the DEM, and point features should be within 3 meters of their location if apparent on the DEM. Okay, so in order to report on the horizontal and vertical placement of the features, we like as many features as possible to be inspected, and we'd encourage the use of automated inspection tools, some of which we're developing now. If a complete review is not possible, a stratified random example should be used, which would include the representatives of all feature types in the data set and represents the complete geographic area for the data set so that that would be samples of features taken from every 12-digit HUC within the defined project area. Also ... Excuse me. Also, the stratified sample should include representatives from special cases within the data set, such as headwaters and confluences between stream reaches and so on, and the stratified sample should take into consideration geophysical regions, land cover, geology types and those kinds of things as well. And now I'm going to ... Oh, no, I'm not. I'm going to talk about the appendices. There are two appendices to the report, the EDH spec. The first is just a list of how these specifications vary from what was previously in the lidar base spec. That was the first place where specifications for elevation derived hydrography were outlined. Also, it includes an appendix with a summary of each one of those specification chapters, so it's a little bit easier to use as a reference. And now I'll turn it back over to Christy-Ann.
Christy-Ann ArchuletaThanks, Silvia. So I'd just like to take a few minutes to talk about the companion document to the specifications, which we talked about before with the long name that we've shortened to the READ Rules. That's easy to remember. The READ Rules describe in detail all of the features that are to be collected and the parameters for collection. The document is designed so each feature type can be separated as a whole from the rest of the document and used by a technician who is working on a specific feature type when collecting that feature type, so if you have someone who's working on collecting stream rivers, they can take that section from the document and have all of the information they need for collection. This is very similar to the way the 1999 NHD standards were set up, so you may be familiar with that. Here is an example of what the READ Rules look like. Let me move on to this in here. In this example, you can see that it provides a definition of the feature. We have all of the attributes that need to be applied to that feature type, so you can just fill in the attributes using this. We have an explanation of how to delineate the feature, so for the area of complex channels, it would be the limit of the channels on the outer banks of the outermost channels. And then for the representation rules, this explains how you want to represent it, whether you want it to be a point, a line or a polygon feature, and that's based on some different measurements you might take of the feature to determine which one to use. Some features have both lines and polygons. For data extraction, we have the capture conditions, and those are usually an if-then statement explaining the measurements. If it's so long, so wide, so big, if it meets these conditions, then you capture it as an area of complex channels. Otherwise, it may be something else. Here is a little bit more information about the attribution, what these attributes mean to help you with understanding the data extraction, and then we have source interpretation guidelines, and we're hoping that we can build on this over time, but this is where we try to provide some information so that if you're looking at different types of scenarios in the data and it may be difficult to figure out what you're looking at, it might give you a little more guidelines there. And then we end each section with a map example to help you recognize what you're seeing on the landscape. So now we'll move on to the next steps. As we mentioned before, we are very close to formal publication. These documents are with bureau right now and should be published very soon. We're also working on a pilot project in Alaska, and that project was based on these specifications. It has its own specifications, but it was based on these, and this study will serve as a test bed for future updates to the specifications in general, and we're hoping we may be able to do some other pilot projects as well. Okay, so if you have any questions or feedback for us, we would love to hear it, and here is our contact information if you want more information.