Al Rea.We'll get started.
This is USGS Hydrography
advisory call.
This is Al Rea.
We've also got Becci Anderson
on the line.
We don't have a whole lot
to announce today
except that the Hawaii data
for NHDPlus High Res
is now available,
so if you are interested
in NHDPlus High Res for Hawaii,
then it is done and available
on our website now.
And so today
we've got Dave Blodgett,
who is in the USGS
Water Mission Area,
and he's going to give us
a presentation
about a number
of different things.
I'll let Dave go ahead
and take it
and introduce
his topic and himself
so, go ahead, Dave.
David BlodgettAll right. So is
my audio good
for everybody?
Al ReaYeah, it sounds good.
David BlodgettAll right.
Well, thanks for having me, Al.
As Al said, I'm with
the USGS Water Mission Area.
I'm part of a Geospatial
Intelligence Branch
within our Integrated Modeling
and Prediction Division.
Al ReaDave, hang on
just a second.
Your sound just went.
We've got an echo here.
I'm going to try muting
everyone again and unmute you.
Okay, Dave?
David BlodgettAll right.
Al ReaOkay.
Dave, let's try it again.
David BlodgettGreat.
Is that okay?
Al ReaYes, that's better.
Thanks.
David BlodgettGreat. All right.
So, yeah, as I was saying,
I'm with our Geospatial
Intelligence Branch
within our Integrated Modeling
and Prediction Division.
I've been working in various
kind of venues on work
related to this
for quite some time.
One of the major motivations
has been
to identify the relationship
between the NHD and the WBD,
and that's been driven
largely by work
that we've been doing
for the National Water Census,
things that were motivated
by the Secure Water Act
to deliver water
availability information,
so water budget
information attributed
to 12-digit
hydrologic unit code watersheds.
So the quest that
I've been on in this space
has led me down a number
of interesting avenues,
one of which was helping
to get a data model
for hydrographic features
or hydrologic features published
through the
Open Geospatial Consortium,
and then various other kind
of national modeling efforts
that I've been engaged
with have had impacts here.
I did a detail with
the National Water Center
working on
the National Water Model,
and a lot of the software
development that was done
for this project was done
while I was there on detail
thinking about the kind of
geospatial framework
for that model
and more recently,
I've been working directly
with the USGS's National
Hydrologic Model,
so distinction there is,
the water model
is an hourly model.
Hydrologic model
is a daily model.
Basically working toward
having operational capacity
for hydrologic modeling
at a variety of scales
that's supported by this kind
of solid basis
of hydrographic
and hydrologic features.
So what I'm going to
present to you today
is some work that is
currently in review,
so take it for what it is.
It's been worked for a while
and is in pretty good shape,
but the manuscript
is in review and [Indistinct]
final, so that's kind of
the status of it.
I'll go ahead and jump in, get
the PowerPoint in focus here.
All right. So the premise
we're starting from
or where we kind of went here
is that there's this dual
concept of drainage basin
and main stem that are really
kind of an organizing principal
for hydrologic landscapes,
and so I did a fairly deep dive
into literature and definitions
going back as far as I could
and found some really
interesting work
from kind of early
quantitative hydrology.
This graphic in particular
is from ...
I don't actually have it
on the slide,
the date but anyways,
it's from, gosh,
I want to say the 1600s
where this is the first diagram
I could find that showed
a drainage basin,
so the dotted line there
ostensibly is the drainage basin
for the Seine upstream
of Paris,
and what I found
really interesting here
is that the Seine's source
is the name of the town,
actually,
so there's a town
in the headwaters of
the Seine called Seine Source,
and I'm not sure exactly
how long that name goes back
[Indistinct].
Presumably people
in this part of the world
knew that the Seine was the main
river in this drainage basin,
and it was some ways
identified as the main river
in this network over time,
and got me thinking that
going back even further,
how did people decide
upstream main stem
before we even knew
the concept of drainage basin?
Before people recognized
that there was a basin upstream
of a place on a river,
there was really no concept
that a river had a source
that was this area,
and the rain in the area
generated the flow.
There were all kinds
of crazy theories
about what created rivers
and how rivers grew
as you go downstream,
so there's a lot to look
at there historically,
kind of how these notions
and how these concepts evolved,
but I really like this graphic
as kind of a very early days
where this comes from.
Okay.
So I've alluded a little bit
to one of the basic issues
we've identified,
and this is just a couple
of key sentences
from the introductory material
of the paper
that we've got in review,
and I've highlighted some of
the important pieces here.
So I have
a great reference book,
"Fluvial Hydrosystems"
from 1996,
by this gentleman, Petts,
and in that,
he described a drainage basin
in a really nice way.
This idea that
a contributing area
as a basic hydrologic unit
of the landscape,
and the quote is that it
encompasses a cascading system
of connected hillslope
and channel subsystems,
so I would say the hillslope
and channel subsystems
are essentially catchments,
and a drainage basin is a
cascading system of catchments,
and it's a total
contributing area. Right?
If you look at Wikipedia
for drainage basin or watershed,
drainage basin is kind of the
root word that you come up with.
If you look
in multiple languages,
drainage basin is a fairly
direct translation,
say, in German to what we mean
when we say
the contributing area upstream
of a place on a river,
and that's helpful.
I think very precise terminology
for this general concept
is important,
so we've kind of run
with this drainage basin term
rather than say watershed.
The reason for that,
watershed is actually defined,
say, in German
was the actual line
that encompasses what we might
call a continental divide.
Right?
The watershed is that thing,
the line on the landscape
that divides two watersheds
or two drainage basin.
So going a little [Indistinct],
we recognize that rivers
have a drainage
basin upstream
of a given location.
This is just kind of
a general thing
that we understand to be true.
Right?
But to add to that,
we also kind of recognize
that there is one main river
in that drainage basin,
and that one main river
is determined
through various
historical artifacts
of what people thought
was the main river.
It's not necessarily
the longest.
It's not necessarily
the biggest.
Many times it's just an
arbitrary societal determination
of a name or whatever it is.
Right?
It's a mishmash of fluvial
geomorphic characteristics,
hydrology,
climatology
potentially depending how big
the river is, etcetera.
Right?
And that's fascinating to me.
It's because this isn't a
strictly physical determination,
what is upstream main stem,
and so all of that kind of leads
to all
the long-held understanding
of what a drainage basin is,
that rivers have upstream
main stem.
That leads to these kind of
really intuitive properties
having a very vague and kind
of general understanding of them
when we start
to talk about them
in technical literature,
for example.
So where that's led us is
that a lot of kind of the data
or the research,
engineering reports of sorts,
they reference
these landscape features,
drainage basins, rivers,
etcetera using loosely
defined language
that's kind of vague,
and that's a problem.
We have a hard time finding,
say,
all the literature
on a particular topic
for a particular river.
It's not as easy
at it ought to be. Right?
And we even have
a hard time, say,
translating where
our streamgages are on rivers
from one data set to the next,
and I'd go back to this issue
of kind of a general vagueness
to how these features
are defined
for why we have
so much difficulty with this.
So that's a little bit
of kind of the background
or maybe a lot
of the background.
It's already 12:15.
So we're now in a position
that this hydrologic
feature standard is out.
It's this standard
for surface features
that kind of recognizes its role
in a surface water framework.
There's ongoing and future work
to be done related
to groundwater,
but for now we've got a lot
to do in surface water,
and so HY_Features is organized
into kind of two ...
There's a duality
in HY_Features.
There's this general notion
of a catchment
due to the thing
that accumulates rain,
delivers it to waterways
and conveys that water
from upstream catchments
to downstream,
so the catchment
is this very holistic thing
that has a dual role
of getting water to other bodies
as well as accumulating flow
in downstream direction
[Indistinct]
to hydrologic networks,
and then this idea
of a hydrologic nexus,
which is the interface between
catchments in the place that,
say, two units of a
hydrologic model might interact
or a place that we might
want to break up our network
because there's a dam. Right?
A hydrologic nexus
is a ostensibly
zero-dimensional feature,
but it's the place where things
combine, things interact,
so we in this main stem's work,
which is what it's come
to be called,
this drainage basin
and main stems.
We are seeking to use
these concepts of kind of nexus
as a conceptual model
and basically applying
those concepts
with a little bit
of refined logic,
and the refined logic
is this idea of drainage basin
and main stem,
so the questions
we were asking in the work
is really at the heart of it is,
can the paired concepts
of drainage basin and main stem
be used to integrate
multiple hydrographic data
sets and to support kind of
linear referencing? Right?
So linear referencing because
we want to be able to catalog
and index observational data,
research,
all kinds of information,
assets that may be at risk
for flooding, etcetera,
and multiple hydrographic
data sets
because there's just
this reality
that we have lots of different
realizations of hydrography
across the landscape,
and we need a way to get them
all kind of working
in the same general framework,
so we wanted to design a very
lightweight logical data model,
but it needed to be able
to handle very complex network
and graph operations
as well as a mixing of data.
And then there's this notion
of hydrologic integration
rather than just
geographic integration
that we raised
in this manuscript
and has really been brought up
in a number of venues,
and if you're familiar with
the idea of being based on place
rather than based
on locality or geography,
that's really what
we're talking about here.
We're talking about a river
or a drainage basin as a place,
a thing that has identity
and may have lots of
spatial representation,
so what we're trying
to get at is,
is there a way to do
a hydrologic integration
based on hydrologic identity
rather than just
geographic identity?
Okay, so a little bit
of review of some terms.
We have this notion
of incremental catchment.
NHDPlus implements
incremental catchment.
They cover the landscape.
They have
a corresponding network,
one internodal reach
for each catchment most part,
and incremental catchments
can make up drainage basins,
and what's interesting is,
drainage basins
because they're nested,
because you can say,
there's the Mississippi.
The Mississippi has the Ohio.
The Ohio has the White.
The White has some creek.
They nest.
At the bottom level
of that nesting,
if you dissolve away
all the boundaries,
or you union
all the boundaries together,
you end up with
incremental catchments,
so that can a set of nested
drainage basins
but then can kind of realize
your incremental catchments.
That's a very important aspect
of this
chronological data model.
The next two here,
headwater and outlet.
I'm pulling those out
because a drainage basin
is ostensibly defined
by an outlet,
and some headwater location.
A drainage basin and a mainstem
is defined by those two points,
and probably the most
important assumption
that we made in this work was,
in a given
hydrographic data set,
the headwater location
should go to the same outlet,
and if those two points
don't join,
if you don't have downstream
main stem as the same location,
that is basically saying
that these two data
sets model hydrology
differently.
There may be a reason
one chooses the diverted path
versus the main path
differently,
but those are the issues that we
actually really do need to find
and tease out to understand
why our hydrographic data sets
are modeling a hydrologic
system differently,
and the last one I have on here
is getting
a little bit technical,
but I think it's very important
to mention
that this mainstem concept
has really already been
implemented in NHDPlus.
It's streamlevel.
Streamleveling, this method of
determining upstream mainstem,
is something that
we've been doing since RF1,
and we've recognized
that there's this
overriding identifier
and then a general geospatial
or geomorphic rule
that we use to determine
what upstream main stem
is in the absence
of an identifier,
and for the most part all we've
really been doing with this work
is exploring level path
and stream level
and applying it in slightly new
and novel ways
and kind of applying some
new workflows to combine data
and find out what we could
do towards these goals.
One of the biggest questions
that we came up with
in this work
is, what is a headwater?
It's not super critical..
this is three hydrographic
data sets.
I believe that this is RF1,
NHDPlus Medium Res
and NHDPlus High Res,
and the point here ...
I know red is RF1.
And the point here is that,
that red line is a first-order
stream from RF1,
and the thick blue line
is the main stem as indicated
by NHDPlus Version 2,
and the black lines
are the full network
as realized by NHDPlus High Res.
And so why, for example,
does RF1 not even have
the main upstream extent
that NHDPlus Version 2 does?
I don't know.
It's not all that important.
The question is,
is this whole area a headwater
because RF1 only has
one first order stream?
Well, no,
it's a headwater in RF1.
The headwater
in NHDPlus Medium Res
is something else maybe up here.
Right?
And in High Res,
which one of these is headwater?
Maybe it's this one.
Maybe it's the one
that NHDPlus Version 2 shows,
but I bring this up because
it kind of makes the point
for hydrologic integration
of these data sets,
what the ultimate headwater is,
is actually defined
by the resolution of the data
sets you're interested.
Downstream of the outlet
of this RF1
is essentially
the most vague definition
of the headwater
of this particular river.
The outlet of the first order
NHDPlus
High Res stream upstream of
where these things
start to diverge
is the most specific point
representation of the headwater
at this particular system,
and we need to be able to
recognize that and handle that.
The direction I've been taking
things I think at the scale of,
say,
the conterminous US,
determining headwater 12-digit
hydrologic unit code watershed,
there's a reasonable
place to be.
That encompasses most of the
headwaters in RF1, for example,
and that size from
how big of a river
comes out of a first order
or a zero order,
depending on how
you look at it, HUC
It's a good general kind
of landscape size to say,
"Those are our headwater areas,"
and any smaller than that,
and things are just going to end
up being kind of weird
depending on the data
set you look at,
and those kinds of distinctions
are really necessary
if we're going to be able
to make progress.
Those kind of simplifications
are critical.
Okay, so we do
the number of case studies,
and I'm going to move through
these fairly rapidly,
but the first case study
that we illustrate in the paper
is the Network
Linked Data Index.
Many of you may have
heard of this.
Essentially
it's an implementation
of level path network
navigation using NHDPlus
Version 2 in a web API,
so the system, you go in.
You say, "I want to start
at that location on the network
and go upstream mainstem."
It goes to NHDPlus Version 2,
navigates and then goes
and finds the things
you're interested along the way,
whether those things
are flow lines,
catchments, a drainage basin,
other indexed locations
such as streamgages
or water quality sites,
and it's fairly rudimentary
in the sense
that it only supports
catchment indexing.
It doesn't support reachcode
and measure directly,
but it does represent
the catchment network,
and it does represent mainstems
and drainage basins
and exercises this notion
of linked data
where you have observation
locations linked to catchments
that are then part
of a mainstem network.
So this showed
the utility of this.
It shows some of the limits
of this work quite well,
but it certainly shows
the power of having
kind of drainage basins
that are aggregations
of incremental catchments
and a main stem network
that connects all that together,
and then how you could connect
that to observation locations
is fairly clear.
There's plenty more work to do
in this space, though.
The second case study
was looking at outlet locations
on one hydrologic
geospatial fabric.
In this case, one defined
for the current version
of the
National Hydrologic Model,
which was built
in NHDPlus Version 1,
and trying to figure out
where the known 12-digit
hydrologic unit
code watershed outlets
fall on that network,
and the nuance with this was,
that we have these 12-digit
hydrologic unit code watersheds
on NHDPlus Version 2,
so the nuance here is,
it's very important to determine
what I've started
to call hydrologic similarity,
not just geospatial similarity,
and that's because we're trying
to say what's the stream flow,
essentially,
at the outlet of a HUC,
and modeling stream flow
requires hydrologic similarity,
watershed
representation similarity,
and that's a little bit
different
than, say, geospatial
or visual similarity.
So a couple of things
we looked at were things like,
how far apart were these
on the network in a linear way?
And so these two diagrams
are just showing
some of the kind of outcomes
of this work,
and we certainly ended up
with some tails,
which is kind of inevitable
in this kind of work,
but, yes, the idea here is,
these kinds of distributions
allowed us to say,
"Well, the ones that are within
so many kilometers essentially
in linear distance,
the distance between
an existing model outlet,
model pour point and a 12-digit
hydrologic unit code outlet."
This allowed us to say,
"Well, this certain
set is close enough.
We're just going to assume
the stream flow
doesn't change much
between those two points,
and this other set,
we need to do something else.
We need to do
some area weighting.
We need to determine
how to estimate flow
for these 12-digit HUC outlets,
and then this other one
is similar
but looking at drainage area,
so normalizing total drainage
area to basically say,
"Well, there are sets
that are close enough together
that we can assume the drainage
areas are modeled the same,
and there's another set
where the drainage areas
are modeled differently.
Do something." Right?
So this wasn't a panacea,
but it was
a very good case study,
a very good way to evaluate
how using this idea mainstem,
we could basically determine
hydrologic similarity
between one set
of watershed outlets
and another kind of pre-existing
set of model unit outlets. Okay.
So the third case study
was working a little more
specifically
to compare the network
of the 12-digit hydrologic unit
code watershed network,
so the "TOHUC" coding
of the HU12s
to the NHDPlus
Version 2 network,
and this was somewhat
to evaluate the quality
or the hydrologic
kind of integrity
of the outlet locations
that Curtis Brice
actually established
from NHDPlus Version 2
in the WBD,
but just more generally it was
an opportunity to evaluate
the "TOHUC" codes and touch
this mainstem paradigm,
and so the graphic on the screen
shows one of the really
common situations
we run into with the WBD,
so the thin black line
is a WBD boundary.
The thicker blue lines
are a river network,
and the arrows kind of try
to show the direction of flow,
so it's very common
that a tributary
just barely comes into a HUC
and then leaves,
and the way that the WBD
often models this is a unit
that just barely enters
and then leaves immediately
is said to go into this one,
so it's said to go into
the one on the left,
and then the one on the left,
the combined flow goes out,
which is literally true
if you Zoom way in
on the geometry
but from a hydrologic point
of view,
from a thinking of these HUCs
as catchments,
maybe, that is not true.
The HUC coming down from the top
here contributes directly
to whatever is down here,
and the HUC on the left
contributes directly to the one
on the right.
This is something
that we can identify
using kind of mainstem logic
and using process of elimination
and main stems to essentially
eliminate HUCs
with this condition.
I won't go into a lot of it.
That's a fairly nuanced
set of analyses that we did,
and if you're curious
about that
and kind of
how that all fell out,
I'm happy to share more
information about it offline,
just contact me.
But this was really
interesting work.
What we found is,
broadly speaking,
the TOHUC codes go
where they're supposed to go,
but there's some not
small percentage
that are not coded in
a especially hydrologic
[Indistinct].
We'll put it that way.
They're not what a hydrologist
would expect
when the drainage areas
[Indistinct]
to each other.
Okay.
So I believe this is
my last case study.
This one I wanted to dig
into NHDPlus High Res
and kind of see
how this corresponded,
so potentially took
some of NHDPlus High Res data
and attempted to track headwater
locations to outlet locations
between Medium Res
and High Res NHDPlus
and just kind of did that for a
large swathe of the landscape
and wanted to look at
the metrics of what [Indistinct]
they're at and broadly speaking,
they go where
they're supposed to go,
but there are outliers,
and this was a great way
to identify places
that either
the Medium Res network
has some kind of downstream
connectivity issues,
or the High Res network has some
downstream connectivity issues
and as you watch
this animation,
you can see some places where
there are definitely some main
path kind of divergences
in High Res
that are not present
in Medium Res,
and I guess there are
some places
where things don't quite agree,
but in general
they agree quite well,
and the main mainstems,
the big ones, are quite good,
but there's definitely
some kind of valuable
QA/QC content
from this analysis
that we could apply to the
High Res network going forward.
Okay. Last one, just for fun,
I [Indistinct]
this with RF1. I've mentioned
this and people go,
"RF1, what?
Why did you go back there?"
And I was like, "Well,
because it's interesting,"
and similar, I threw up
this a second ago.
We basically found that
RF1 headwaters diverge
sometimes a lot earlier
than you might expect,
but by and large the main
mainstems, everything agrees.
Once you get too far downstream,
RF1 does some funny stuff
with water bodies,
but for the most part
this was a really valuable
and kind of interesting
piece of work
because it verified
that some of the core
kind of big network pieces
are intact
and work the way
they're supposed to,
so I'm feeling
pretty good about this.
The outcome of this work is
essentially a table that says,
"Here is the headwater and
the outlet for a given mainstem
in all the data sets
that I just listed,"
and as we work forward,
we'll be able to have
this essentially look up table
to mainstems that says,
"Oh, you have something
on that mainstem?
Well, go get that path
from that other data set
if you want the same
mainstem worth of data,"
and having that for this kind of
general purpose mainstem-based
crosswalk that obviously has
these associated drainage basins
can become a tool
for us going forward,
but we have these
open questions,
and I think the biggest one
in my mind is this idea of,
when we say headwater,
what do we mean?
Where is this thing
we call headwater?
It's defined based on
the resolution of the data
you're looking at,
and it's defined on,
how hard has it been raining
lately potentially?
And this is really important
for some of the conversations
we have WOTUS right now.
This, where does
the blue line start?
And why?
Is a really nuanced question,
and it's something that's
becoming increasingly important,
so that's my future
work question one.
So can we identify consistent
and defensible logic
for creation of the headwater?
And this is something
in creation
of NHDPlus Version 2,
for example.
They did generate
catchments upstream
of the top end of the blue line,
but those polygons
weren't saved.
I think that's a really
interesting analysis,
the what is the zero-order
catchment
that contributes to either
the top end of the blue line
or the shore of a lake?
And that's the second question.
Those are really
interesting questions,
how far upstream or how big of
a water body do you draw? Right?
Based on mean
annual water body area.
That's a tricky question,
and so the second big one
that we've run into again
and again is,
what is this relationship
between catchment features
and water bodies?
Clearly we end catchments
at the ocean.
We end catchments
at the Great Lakes.
We end catchments at Lake
Winnebago in Wisconsin,
but we don't end catchments
for smaller lakes
and smaller water bodies
or even fairly wide rivers.
The wide river flows
through a catchment.
We don't break
the catchment network up.
Well, we got to tackle that.
That's a data model problem
that is not solved,
and it's something that is
going to take some work,
so I think those are the two
biggest kind of like,
wow, we have more work to do,
but at the core
of what we've done,
I'm feeling really good about
this kind of logical data model
based on mainstems
and drainage basins,
so I put in some material
about the tool chain
that's been developed
along the way here
that I just wanted
to kind of mention briefly.
If we have more time and people
want to ask questions,
I'm happy to go deeper
into any of these topics,
but my workflow is -
caveat- up as provisional
and in process,
but it is available on GitHub,
so I'll start
at the bottom here.
This thing I've been referring
to as mainstems is available
as a repository,
bring this here,
so all the R code,
all the workflow stuff is here.
It's runnable. It's available.
Actually, some of the graphics
I used in this presentation
are just in here as examples
of the output of this workflow.
Everything is implemented using
a workflow tool called Drake.
It's a kind of directed graph
reproducible data science
workflow tool
that's really nice.
I'm really happy with it.
Much of the reusable code
that's been developed
along the way of this work
is actually in a package
called NHDPlus Tools,
so if you haven't
come across this yet,
and you work in r-spatial
at all, it is on CRAN,
recently passed 2,000 downloads,
so a number of people
are using this.
I'm pretty happy with
how this has come together.
Still kind of in a version
zero point something.
I think I see a path
to a version one.
There's some changes
that I definitely want to make
before this is something
that I'm super happy with,
but it's a great resource,
something to be aware of,
especially if you're working
in the R-spatial world.
And then the last thing is just
if you don't work on r-spatial,
I highly encourage you
to check out r-spatial.
There's an ArcGIS bridge package
if you want access to,
or you need access to an ESRI
licensed set of capabilities.
There's a good set
of kind of ways
to go back and forth
between the two worlds,
and it's a really impressive
set of geospatial
and kind of data science
processing tools
and visualization tools.
Some of the mapping capabilities
are really impressive,
so for example,
with just one line of code
in NHDPlus Tools using R,
you can get a map
of the NHDPlus network,
a drainage basin
and a nice little base map
upstream of the streamgage.
This is all really simple,
straightforward R capabilities.
Much of this is work I did to
get working in NHDPlus Tools.
But if you're not familiar
with the r-spatial world
and some of the stuff
that we can do in kind of
these data science tool chains,
I really encourage you to spend
just a little bit of time
Googling around
and seeing what's out there
because it's really been
transformative for my work,
and in this day and age,
writing a few lines of code
is a really good thing
to dig into kind of regardless
of what your role is day-to-day.
So that's what I had.
I have a few more slides
to get into more details,
but I will stop there
and open up for questions
and kind of see where people
want to take the conversation
rather than going
on any further.
Thank you for your time.
Thanks for listening,
and if there are questions,
I think you can unmute yourself.
Al ReaI'm going to ...
David BlodgettI don't want
to do that.
Al ReaI'm don't want
to unmute all.
I'm going to mute
all again, sorry.
So, yeah, in the participant
panel of the Webex,
there's a little icon
for your microphone.
You can unmute yourself.
If you called in and didn't put
in your user code,
then you're one of those
call-in user number something.
So does anyone have questions
for Dave?
AttendeeHey, hello, this is
Sean Vaughn from Minnesota.
Al ReaHi, Sean.
AttendeeGood afternoon.
I do have a question for David,
and it's maybe not a question
but a few statements here.
A lot of this work reflects what
we've done here in Minnesota.
I think any times we talk
about these outlets
and the correlation between
an outlet and a main stem
and why we have watersheds
or catchments,
drainage areas, if you will,
that encompass lakes
is because
the history of our agency
is mapping watersheds
to meet a size criteria.
I felt very strongly
for quite a number of years
that to overcome that,
we really have to recognize
that we should be parsing
a landscape up
by what we here
at Minnesota ideally
would call hydrologic
point of interest,
so a lake outlet
would be the pour point,
and the pour point
would be the indicator
for the watershed drainage area
upstream from that point.
The other thing
that we're losing here
just for something for
the entire team to think about,
something I've brought up
I past meetings
and other venues as well
is the issue of scale.
I always think about scale
in the traditional sense
and in particular one point
where [Indistinct]
is really changing,
and we have to think about,
what is the role of lidar data?
And how does that relate
to resolution?
Here we see resolution
becoming more
of a definitive factor of scale
and that recognizing
that lidar captures water
[Indistinct]
land forms that then allow us
to bring our delineations
further up into the landscape
to be the all-encompassing
drainage area system.
So two key takeaways out
of there is thinking about,
what is the role of lidar?
Then what is the role
and discussion
around scale versus resolution
for this type of work?
Al Rea[Indistinct].
David BlodgettGreat points.
I couldn't agree with you more,
and, yeah, I think part
of the determination
of what water bodies you carve
out of the landscape
versus what waterbodies
do you keep kind of
within your catchment
network is,
what do you need a point
of interest downstream of?
Yeah. But then as soon
as you zoom in
and change the kind of
fidelity of your data,
that distinction might change,
and it gets complicated,
so, yeah, it's good stuff,
and it's great stuff
to be looking at and yeah.
Al ReaAny other questions
for Dave?
So, Dave,
I'll throw one at you.
So let's say I was interested
in learning
about R and coming at it
completely fresh.
Where would I start?
David BlodgettCompletely fresh,
there are a number of really
good resources if you ...
If you just Google USGS R,
there's some great introductory
R training materials
made available by USGS Water.
From there,
there's a fantastic book
that's actually linked
from the r-spatial.org web page,
and there are a number of really
good resources in this vein,
so there's "Spatial Data
Science" by Edzer and Roger,
who are kind of two of
the main leaders in this space.
There's another geospatial
processing in R.
Let me just search for
geospatial processing R book.
It should come up.
Yeah, Robin Lovelace
has this book
called
"Geocomputation With R."
That is fantastic.
Between these two,
you've got more resources
than you probably know
what to do with
to get you
kind of into things,
and the beauty of these books
is, they're written in R.
They're written using Markdown,
and if we look down
into some of the ...
So there are
copy-pastable examples
throughout these resources,
so I could copy and paste
this directly into RStudio,
and things just run and work,
and so you could use
the examples directly.
And that would be [Indistinct]
kind of say is just install
RStudio and start playing,
and when you get an error,
Google the error message
and play some more.
If you didn't know,
Googling the error message
is 99 percent of programming.
Al ReaOkay.
Yeah, so I don't know.
Maybe I'm speaking
just from my own experience,
but I suspect there are
a lot of people on our call here
who are pretty heavily
in the Esri ecosystem,
and a lot of people
I don't think have been
exposed much to R,
and maybe they're
just not familiar.
I certainly am not
very familiar with it.
David BlodgettYeah, so there
is an R bridge.
My understanding of it is,
it's the similar tool chain
to the Python package for ArcGIS
but in the
R programming language,
so that would be a place
to start
if you're familiar with ArcGIS
and want to explore
the R ecosystem.
I know that it gives you
direct access to the sf,
so sf is a package in R
that is kind of the bread
and butter
for doing this kind of work.
So I know it gives you access
to the sf
directly from ArcGIS data types,
but this would be
the other thing
to take a look at
is the R bridge.
One other thing I guess
I would mention is,
if you can make it to the AWRA
Geospatial Technology
Conference, there's a workshop
the day before the conference
starts on geospatial
processing R where Mark ...
I'm blanking
on Mark's last name.
Anyways,
the gentleman from the EPA
and I are going to be teaching
a workshop the day
before the opening of the
Geospatial Technology Conference
that's coming up in March,
and there are plenty
of other opportunities
to get training
in this kind of stuff.
Al ReaGreat.
Any other questions?
David BlodgettMarc Weber,
thank you.
David BlodgettYou've
stunned everyone, I think, Dave.
Either that or ...
David Blodgett[Indistinct]
sorry, [Indistinct].
Al Rea... [Indistinct].
I'm going to ...
David BlodgettSomebody
just raised a hand.
Al ReaI'm going to try
to unmute everyone here
just in case
there's anybody desperately
trying to say something
and, yeah,
just got the feedback.
>> [Indistinct] so ...
Al ReaI think with that point,
we'll call it a day.
I'm going to mute
everybody again.
