InfoVeg

Steve writes: 

	Hello everyone,

	Recent discussions with regulatory agencies and a few internal

	realizations regarding how EEP will deal with problematic projects has

	prompted Greg Melia to begin arranging the stream morphology data

	according to Reaches, which are basically sections of stream(s) within

	restoration projects that are relatively similar in terms of: watershed

	area, profile, restoration design approach, etc.  The driver behind this

	decision is the fact that we may start receiving mitigation credit for

	some reaches within a restoration project while other reaches are

	stabilized and abandoned, at least temporarily, from the standpoint of

	claiming mitigation credit.  This creates a need for us to be able to

	assign Reaches to each of our veg plots (stream restoration only) so

	they can be queried by project/reach.

	Please consider the affects this has on the Protocol, Datasheets and

	Database.  For the protocol, I will coordinate with Greg and provide

	text that will basically direct readers to the appropriate EEP document

	for a more complete explanation of how Reaches are defined, and to the

	appropriate required drawing that will depict the location of each

	Reach.  Of course, Mike should begin creating room on the Datasheets and

	begin adding this feature to the Database.  To keep things relatively

	simple, consultants will not be expected to determine the reach of each

	plot during this year's monitoring effort. The can be applied to VBD for

	new projects once everything is updated, but will not be required for

	annual monitoring until 2008.  In other words, there is no need to

	rush.  Regardless, if this proposed change is more complicated than I

	suspect, please let me know promptly.

	In the mean time, Greg and I will also look at a few project examples to

	determine if the current required number of plots is adequate for this

	new stratified/representative sampling approach.  We may find that an

	increase in the number of required plots is necessary in order to

	capture vegetation data from each reach in addition to capturing a

	representative sample of the entire project.

	More later...

	Thanks,

	Steve

Bob replies:

	Hi Steve et al.,

	My sense from reading your document is that "reach" will be an attribute

	of a plot that is subject to change.  You may, for example, wish to shift

	a plot from one reach to another as you figure out how much of a project

	you can claim credit for under various assignment scenarios.  Thus, we do

	not want to make reach another component of the the current identifier

	triplet of project-team-plot.

	Do we want to track the changing assignment of plots to reaches, and who

	do we want to have access to these data?  Also, so we want to keep track

	of previous assignments and the start and stop dates of those assignments,

	or just the current assignment.  We could add a REACH table to our

	database that contains the following variables

	[projectID/plotID/reachIdentifier/startDate/endDate].  There is nothing

	here that precludes a plot belonging to more than one reach at a time,

	though we could have that business rule.

	There is also the questions of whether we want EEP to be able to

	frequently change assignment of plots to reaches within our database, and

	if so how that should be accomplished.  I suppose a web interface could be

	built, but that would be a hassle for us, though perhaps less of a hassle

	than getting a steady stream of emails asking for changes and then needing

	to generate fresh reports.

	I am currently inclined to follow up on our plan to send EEP a copy of

	the populated database annually by providing a component tool for EEP to

	go into the database and fiddle with assignments to reaches, after which

	they could rerun the summary tables as by reach as needed.  The two new

	things we need to add here are a modest interface for adding and editing

	assignment of plots to reaches, and the ability to generate reports by

	reach rather than just project or plot.  We would also need to have the

	database be able to update new versions of the database with extant reach

	assignments.  With this plan all information on reaches stays within EEP

	and never migrates to our shop.

	Let me know if you think this is relatively close to the mark.

	Bob

Steve again:

	Hello again,

	I regret not being more clear about reaches in my first email.  The

	reaches are defined during the design process and do not change.  The

	only scenario I can think of in which EEP would want to request a change

	is if an error regarding the reach assignment were discovered.  Please

	respond and let me know how this affects your recommendation.

	Also, the word-smithing is appreciated.

	Thanks,

	Steve

Tom:

	Hello,

	Having read this as well as Steve's clarification, it seems to me that all

	that is required here is an additional field in the location area of the

	data forms, and also the corresponding field in the database, to

	accommodate the assignment of a reach to each (new) plot.  Steve, do you

	have an example of the coding or nomenclature system used to designate a

	reach?

	Cheers, Tom

Bob:	

	If reaches are stable, then life is easy.  However, I can easily imagine

	EEP moving toward a plan where reaches adjust to reflect restoration

	success.  I would be interested in Greg's reaction to my email below.

	Bob

Steve:

	I know what you mean.  In fact, I recall a meeting approximately 2 years

	ago in which a proposal to track monitoring data by reach was made, and

	then declared to be "impossible" based on the number of reaches that

	will eventually be scattered throughout the state....

	Regardless, I spoke with Greg and he assured me that reaches will not

	change.  If a portion of a reach fails, we have the ability to subtract

	the linear footage of the failure, instead of readjusting the reach

	limits.  Tracking the success and failure of a project according to

	reach simply allows us to focus our data in areas that are expected to

	behave differently over time.

	The terminology and document references needed for the protocol will be

	provided by Greg, once all the related documents are finalized.  Given

	our current workload and varying priorities, that may take a couple months.

Bob:

	This is reassuring in that it makes all of our lives much easier.

Michael:

	Hi all,

	I am catching back up on emails.  I'll summarize where I think we are here:

	1) reaches are assigned to plots (or vice-versa) in the design phase

	2) plots don't change the reach(es) they are assigned to

	3) can a plot be assigned to more than one reach??

	4) Greg will be sending some information on what a reach is, exactly,

	and how we might label them with a name

	5) this isn't urgent at present.

	I'm still not real clear on what a reach is.  It seems to be a

	categorization of plot based on location and environmental variables.

	I'm not sure if a project will be mostly within one reach, or if it

	will have a few reaches, or if most every plot will be in its own

	reach within a project.

	--michael