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