InfoVeg

apparently we now have the data from Jenn.

Forbes will check his files to see what has already been accomplished.
I scanned some emails and found some files put into the updates_ready/updates_completed folder, which is not the correct location for updates that need to be commited to the database.

I moved those files to:
\\Bioark\peetlab\CVS\CVS_UpdatesReady\elevation
which is a new subfolder of CVS_UpdatesReady. There may be some version control issues there.

I have also added a text file that copies the relevant email threads I can find on the subject called elevation_email_threads.txt

We talked on 1/28/09 about the need to make sure the plot coordinates are pretty accurate before using the DEM elevation value. It may be possible where plot coordinates are not as accurate to use a average or median of a range of values from the area were the plot is likely to be, if we have the full DEM.

FORBES BOYLE WROTE ON EMAIL:

The most-up-to-date version of elevation can be found:

\\Bioark\peetlab\CVS\CVS_UpdatesReady\elevation\CVS_Elev_Jan2009

This spreadsheet contains three derived elevation fields: 1. CVS_ELEV: The original elevation data recorded in the elevation field of either the archive database (< proj 61) or the entry tool of a specific project (> project 61), 2. ELEV_DEM30m_int: Data provided from Jen Costanza, obtained from 30 meter resolution dem’s from certain sections of North and South Carolina only, and 3) ELEV_TOPOZONE: Elevation records obtained from plugging in x,y coordinates into the topozone website, sometimes regardless of location precision.

If we choose to whittle our three elevation fields down to one, I have created the field CVS_ELEV_2009. Here is how the values in the field were derived:

1. If a record (plot) only contained one of the three derived fields, that value was copied into the CVS_ELEV_2009 field.
2. For records that contained two of the three derived fields:
a. If mountain/piedmont derived fields were <= 50 meters apart, I calculated the “mean†of these two fields to go into CVS_ELEV_2009.
b. If coastal fringe derived fields were <3 meters apart, I calculated the “mean†of these two fields to go into CVS_ELEV_2009.
c. If sandhills derived fields were <=10 meters apart, I calculated the “mean†of these two fields to go into CVS_ELEV_2009.
d. If coastal plain derived fields were <5 meters apart, I calculated the “mean†of these two fields to go into CVS_ELEV_2009.
e. If derived fields exceeded these errors (>=50, >3, >=10, >5 meters), a third value was calculated from TOPOZONE.

3. If the record contained all three fields, I took the mode of the three values. If there were no mode, a judgment call was made. (sometimes all three values were averaged; if there was an outlier value, only two values were averaged).

Other notes:

1. If a plot had a Lat Long error greater/equal than 1000 meters, no elevation data were calculated for CVS_ELEV_2009, regardless if previous values were given in any of the above three derived fields.
2. No data were calculated for project 43 (Carr;s Florida longleaf).
3. The value “8888†within ELEV_DEM30m_int translates to NO DATA.

More email comments copied here:
From: Robert K. Peet
Date: Sat, Jan 31, 2009 at 11:24 AM
To: Forbes Boyle
Cc: Michael Lee

Thanks Forbes,

Some comments follow. I think we need one elevation, representing our best understanding.
We might want to add a field indicating how we obtained this. OK I am uneasy with this. Investigator estimates from maps generally tend to be better than 30mDEMs, except when errors are made. My inclination is to stick with the original entry unless there is a reason to doubt it (eg, wide deviation). ditto above ditto above ditto This is OK only if location precision is tight (eg <=50m). Elsewise we need to look at each individually and make a call. I am a bit uneasy about this one. If the number is manageable, I would look at each individually and make a call. We have high-quality geocoordinates for project 43, so we should make a point of looking up the elevations using topozone
Use: CVS\CVS_Projects_43_FloridaLL\Project43-Elevation-Jan2009.xls OTHER NOTES

I am not sure I am ready to accept plots with negative elevation. Perhaps all the negatives should be set to zero?

Let's limit the precision to 1 decimal place

612 plots still lack elevation in the CVS_ELEV_2009 column. Some of these have old CVS values. Where we have old cvs values and the location error is unfortunately > 1000, let's just keep the old CVS and assume the author knew what she was doing (eg Project 25, 17). As noted above, let's look up the project 43 values.

bob

----------
From: Forbes Boyle
Date: Sat, Jan 31, 2009 at 11:50 AM

To: "Robert K. Peet"
Cc: Michael Lee

Hi Bob,

To clarify: For records that have three elevation fields (original CVS
data, Jen's DEM, and Topozone), you want the new elevation field to
represent the original data ONLY?? Unless there are some major deviations?

----------
From: Robert K. Peet
Date: Sat, Jan 31, 2009 at 12:19 PM
To: Forbes Boyle
Cc: Michael Lee

That would be my knee-jerk answer, but I could be talked out of it. What do you think?

Bob

More email found:

From: Forbes Boyle
Date: Sat, Jan 31, 2009 at 12:54 PM
To: "Robert K. Peet" , Michael Lee

The updated elevation table is still located here:

\\Bioark\peetlab\CVS\CVS_UpdatesReady\elevation\CVS_Elev_Jan2009

I have added a new elevation field titled “CVS_ELEV_2009b”, per Bob’s previous instructions. Some notes follow:

1. For plot records that contain ALL three derived elevation fields (CVS_ELEV, ELEV_DEM30m_int, and ELEV_TOPOZONE), the new CVS_ELEV_2009b = CVS_ELEV, unless the difference between CVS_ELEV and ELEV_DEM30m_int is greater than 500 meters. For these instances, an average of ELEV_DEM30m_int and ELEV_TOPPOZONE will be used in the CVS_ELEV_2009b field. ****Let me know if you want to increase/decrease the 500 meter cutoff.

2. For plot records that contain CVS_ELEV and ELEV_DEM30m_int, the new CVS_ELEV_2009b = CVS_ELEV.

3. For plot records that contain CVS_ELEV and ELEV_TOPOZONE, the new CVS_ELEV_2009b = CVS_ELEV.

4. For plot records that contain ELEV_DEM and ELEV_TOPOZONE, the new CVS_ELEV_2009b = average of the two derived fields.

5. For plot records that contain only CVS_ELEV, the new CVS_ELEV_2009b = CVS_ELEV

6. For plot records that contain only ELEV_DEM, the new CVS_ELEV_2009b = ELEV_DEM, unless location accuracy estimate is > 1000 meters.

7. For plot records that contain only ELEV_TOPOZONE, the new CVS_ELEV_2009b = ELEV_TOPOZONE, unless location accuracy estimate is > 1000 meters.

8. Negative values raised to “0” meters

9. Values rounded to 0.1

M. Forbes Boyle

mboyle@unc.edu

Project Manager / Carolina Vegetation Survey

University of North Carolina

409 Coker Hall, CB 3280

Chapel Hill, NC 27599

Office Phone: (919) 962-6934

Cellular Phone: (919) 265-7505

----------
From: Michael Lee
Date: Sat, Jan 31, 2009 at 3:10 PM
To: Forbes Boyle
Cc: "Robert K. Peet"

Is it correct to say that the other files in that folder are out of
date and should be squirreled away in an "old" or "outdated"
subfolder?
--michael

----------------------------------------------------------------
Michael Lee
Database Programmer and Administrator
Carolina Vegetation Survey
http://cvs.bio.unc.edu/
michael.lee@unc.edu
----------------------------------------------------------------
Want CVS-EEP News and Updates?
--Send an email to listserv@unc.edu
with message text (not subject):
subscribe eepveg

----------
From: Robert K. Peet
Date: Sun, Feb 1, 2009 at 3:37 PM
To: Forbes Boyle
Cc: Michael Lee

Hi Forbes & Michael,

I am a bit uneasy with this. I don't think it is quite what we want. I have created a draft decision tree (attached). Please look it over and let me know what you think?

Bob

----------
From: Michael Lee
Date: Tue, Feb 3, 2009 at 11:04 AM
To: "Robert K. Peet"
Cc: Forbes Boyle

Hi Bob, Forbes,

I like the table you created, Bob. I agree with you that we don't
necessarily want to power through the elevation values that are
already in the database and replace values with DEM values. The table
essentially treats the Coastal Fringe, Coastal Plain, Piedmont, and
Mountains in the same manner, just with larger and larger error
tolerance as we go west.

I am still curious about how geocoordinates are looked up on TopoZone,
as they tell you what the center elevation is on some views there: do
we use that? Or do we look at the elevation lines that are drawn on
the topo maps? I can create a link from the viewer into TopoZone to
automate pulling up the Topozone webpage, but I need to know which
view is wanted in Topozone, there are so many now that they reworked
that site.

Also, I found an auto-lookup for DEMs online for other projects that
we don't have DEM values for. It would be a good QA to throw our
coordinates at it that we have DEM elevations for from Jenn to see if
they are giving us the same values. If not, we might use it with a
bit more skepticism, if at all.
http://www.latlontoelevation.com/dem_consume.aspx
I'm happy to do this if it's seen as worthwhile.

----------
From: Robert K. Peet
Date: Sun, Feb 22, 2009 at 6:30 PM
To: M Forbes Boyle , Michael Lee

Where are we with elevation?? An update would be nice.
Bob

----------
From: Forbes Boyle
Date: Sat, Feb 28, 2009 at 11:53 AM
To: "Robert K. Peet" , Michael Lee

Hi Bob, Michael
Attached is the updated elevation table, complete with province
determination for CVS plots.
The copy of record fort this spreadsheet can be found:
Best
Forbes

----------
From: Robert K. Peet
Date: Sun, Mar 1, 2009 at 11:54 AM
To: Forbes Boyle
Cc: Michael Lee

I am a little confused. Why are some values 0 when CVS has a positive value? What is the status of the ones labeled exam?

Bob

----------
From: Forbes Boyle
Date: Tue, Mar 3, 2009 at 1:29 PM
To: "Robert K. Peet"
Cc: Michael Lee

Not sure what's wrong with the "0" values that you've mentioned.

The "EXAM" is abbreviated for examine. These are for records where CVS_ELEV
deviates by > 3 meters from either DEM or TZ, and we haven't undergone a
third method for obtaining data. There are about 60 of these cases that
should be looked at individually on topo maps. I could put our hourly
employee on this, but first I'd like to look at some individual cases to see
why they weren't "topozoned" in the first place.

----------
From: Michael Lee
Date: Thu, May 14, 2009 at 4:20 PM
To: Forbes Boyle
Cc: "Robert K. Peet"

Hi Bob and Forbes,

These elevation updates are done, except for 60 that require
examination and are marked "EXAM" Additionally elevation accuracy
wasn't specified in our rules. I used the following:

Err minElev maxElev
5 -10 50
10 50 200
30 200 1000
40 1000 2000

How does that look?

The remaining plots to examine are in:
\\bioark\PeetLab\CVS\CVS_Updates\UpdatesReady\elevation

There are 60 marked "EXAM" and 540 other without any elevation at all.

Geocoordinates are also updated, and a new province field is populated
for the plots that had that in them in the elevation table from
Forbes.

I will try to get all that wrapped into a new analysis database, plus
project 84 for tomorrow.

elevations have been updated except for ~50 that are marked EXAM.

There is also a pile that needs looking up. I've asked Jackie how to do that in ArcGIS. I can't get the raster elevation datasets to merge with plots for some reason.

Original Bugzilla ID was 3532