InfoVeg: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362009-09-30T18:00:52ZEcoinformatics Redmine
Redmine Bug #4428 (Resolved): Constancy wrong for classified plots that have no specieshttps://projects.ecoinformatics.org/ecoinfo/issues/44282009-09-30T18:00:52ZMichael Leemlee@nceas.ucsb.edu
<p>Plots with no species need to be ignored in constancy table generation. Can still be mapped though.</p> Bug #4377 (Resolved): Improvements to Community Webpageshttps://projects.ecoinformatics.org/ecoinfo/issues/43772009-09-10T18:34:21ZMichael Leemlee@nceas.ucsb.edu
<p>1) add community name (scientific and common)<br />2) Add woody strata (T/S)<br />3) Add # stems, BA<br />4) Switch to percentile instead of range for soil sliders<br />5) Switch position to within 4 main group region instead of full dataset<br />6) eliminate soils fields: %'s, coarse, N,P<br />7) add elevation, slope, aspect (how, sine transposition?), incident solar radiation (find data)</p> Bug #3916 (Resolved): Evaluate georeferencing standards of CVS (and VegBank)https://projects.ecoinformatics.org/ecoinfo/issues/39162009-03-24T13:30:56ZMichael Leemlee@nceas.ucsb.edu
<p>When you have some spare time, please take a look at this reference and check to see the level of consistency of CVS and VegBank with the best practices reported here. The document looks quite comprehensive. I look forward to your evaluation.</p>
<p>Chapman, A.D. and Wieczorek, J. (eds). 2006. Guide to Best Practices<br />for Georeferencing. BioGeomancer Consortium. Copenhagen: Global<br />Biodiversity Information Facility. 90pp. ISBN: 87-92020-00-3.<br /><a class="external" href="http://www.gbif.org/prog/digit/data_quality/BioGeomancerGuide">http://www.gbif.org/prog/digit/data_quality/BioGeomancerGuide</a></p> Bug #3844 (Resolved): none-of-the-above community placeholder: EntryToolhttps://projects.ecoinformatics.org/ecoinfo/issues/38442009-02-25T20:30:15ZMichael Leemlee@nceas.ucsb.edu
<p>3) We need a placeholder for "none of the above" when a plot does not fit into<br />ANY community within a particular framework.</p> Bug #3799 (Resolved): Create taxon collection list inside the Entry Toolhttps://projects.ecoinformatics.org/ecoinfo/issues/37992009-01-29T21:46:48ZMichael Leemlee@nceas.ucsb.edu
<p>Currently each project has a taxon collection excel spreadsheet that is generated by the person sorting through dead plants. It would be great if the entry tool could incorporate that into the tool itself, so that the list of taxa that were collected would be displayed (and sortable by plot, or other characteristic). Alternately, the entry tool could create the template of this information and port it into Excel.</p>
<p>If it remains in Access, then the updates that are made would automatically be part of the entry tool.</p> Bug #3797 (Resolved): Entry DB should have an initialize function for DBAhttps://projects.ecoinformatics.org/ecoinfo/issues/37972009-01-29T20:32:17ZMichael Leemlee@nceas.ucsb.edu
<p>There are a few things that would make life simpler for the DBA when starting off a project.</p>
<p>The Entry Tool could import plot #s, lat/long, and contributors from the OmniSheet in excel. Maybe place names, too?</p>
<p>We need standard naming of the tabs of the Excel for that to work easily.</p>
<p>It should use party names that are already in CVS when they are recognized, otherwise add new parties.</p> Bug #3790 (Resolved): Public/Private versions of Analyis databasehttps://projects.ecoinformatics.org/ecoinfo/issues/37902009-01-29T19:44:02ZMichael Leemlee@nceas.ucsb.edu
<p>We would like to create a public version of the analysis database that can be used by anyone, with all sensitive data appropriately handled. The timeline on this bug is not clear at present.</p> Bug #3789 (Resolved): create "export to VegBank" functionhttps://projects.ecoinformatics.org/ecoinfo/issues/37892009-01-29T19:42:49ZMichael Leemlee@nceas.ucsb.edu
<p>Since the data structure are very similar in VegBank and CVS, it should be fairly easy* to copy code from VegBranch to the Viewer so that someone could create XML to ship to VegBank for inclusion there.</p>
<p>The scope for this would be about a project in size, perhaps broken into pieces if one file would be too large for VegBank.</p>
<p>We will have to consider how much data to send about each plot. Some of the questions:<br />1) send plots with nested subplots for each module, or just "parent" plots<br />2) how many of the extra fields created for use in CVS should be added as user-defined data<br />3) very careful QA will be needed to make sure that embargoed/confidential/sensitive data are not transmitted about plots, e.g. all plot location information about some plots.</p> Bug #3788 (Resolved): Check county,state using geocoordinates with taxacom scripthttps://projects.ecoinformatics.org/ecoinfo/issues/37882009-01-29T19:39:06ZMichael Leemlee@nceas.ucsb.edu
<p>Bob has encountered a script on the taxacom mailing list that allows someone to validate (or lookup?) county and state based on geocoordinates. This would allow us to flag problems and figure out which is wrong: county/state or geocoordinates.</p>
<p>This is tricky for plots on rivers where the river is the county boundary (I tried to do some of this once with Roanoke, and that was the source of a lot of errors).</p>
<p>I cannot find the script in taxacom's archives, either in my email or on the web:<br /><a class="external" href="http://mailman.nhm.ku.edu/pipermail/taxacom/2009-January/subject.html">http://mailman.nhm.ku.edu/pipermail/taxacom/2009-January/subject.html</a></p>
<p>Bob will forward the script and instructions to Michael, who will handle the lookup and cross-walk against the database and flag errors. Then someone will have to deal with the errors.</p>
<p>Similar to bug 3532, we will have to consider error in plot coordinates as one possible explanation for flagged problems in county/state.</p> Bug #3613 (Resolved): run revision project 32: 4 stems in old archive "bigstem" table are too smallhttps://projects.ecoinformatics.org/ecoinfo/issues/36132008-11-09T00:15:47ZMichael Leemlee@nceas.ucsb.edu
<p>plotID<br />052-01-0800<br />050-01-0039</p>
<p>have stems sizes 4,5,1, and 0 respectively. These are errors and the raw datasheets should be checked.</p> Bug #3611 (In Progress): Newell R module = supersample?https://projects.ecoinformatics.org/ecoinfo/issues/36112008-11-08T05:54:33ZMichael Leemlee@nceas.ucsb.edu
<blockquote>
<p>I have discovered a rather surprising anomaly in our database. I am<br />working on making sure that the calculation of R module size is<br />correct for tree stems, which is necessary for getting basal area<br />correct, at least at that modular level. This is relatively<br />straightforward, because the tree size of the plot is known, and so<br />are the number of intensive tree modules (generally- sometimes if no<br />trees are in a module, it doesn't get recorded and so it's not clear<br />if the empty module is really empty or part of R. This email is not<br />addressing that minor issue).</p>
<p>There are 30 plots in the database that have the same number of<br />intensive modules as tree plot size (e.g. plot size of 2 and intensive<br />modules are 1 and 2) that ALSO have tree module R. So it begs the<br />question, what is the R module representing. Claire Newell's plots<br />(project 10 and 11) are the only ones this way, and all of them are<br />supersampled. It seems clear to me that the R module is where she<br />parked the extra stems from supersampling, which is to say that the<br />intensive module numbers are NOT supersampled. The R module, when<br />added to the 1 or more intensive modules, would accurately represent<br />the super sample.</p>
<p>So I'm not exactly sure what to do about these. Her data do make<br />sense if only analyzed at the plot level, ignoring the modules. That<br />would be option A for these plots: remove all module information and<br />call all rows module R. I briefly thought about creating R modules<br />and increasing the plot size to match them, but the difficulty there<br />is that not all species are supersampled always, thus module R is not<br />really a complete module. That would be option B, which I no longer<br />consider hopeful. Option C would be to split up the R modules's stems<br />and distribute them amongst the various intensively sampled modules,<br />of which there are 4 times only 1 (that's easy enough), 19 times 2<br />modules, 3 times 3 modules, and 4 times 4 modules.</p>
<p>I like option A: to remove all intensive module information from these<br />30 plots and then the supersampling is accurate. Please let me know<br />(soon) what you would like me to do.</p>
<p>To see the raw data, see text files:<br />\\Bioark\peetlab\CVS\CVS_Projects\10_Linville\10_trees.arc<br />\\Bioark\peetlab\CVS\CVS_Projects\11_Shining\11_trees.arc<br />plots:<br />010-0C-0013<br />010-0C-0020<br />010-0C-0025<br />010-0C-0027<br />010-0C-0029<br />010-0C-0053<br />010-0C-0056<br />010-0C-0057<br />010-0C-0059<br />010-0C-0062<br />010-0C-0082<br />010-0C-0085<br />010-0C-0087<br />010-0C-0091<br />010-0C-0096<br />010-0C-0097<br />010-0C-0101<br />010-0C-0112<br />010-0C-0176<br />011-0C-0302<br />011-0C-0309<br />011-0C-0314<br />011-0C-0350<br />011-0C-0396<br />011-0C-0400<br />011-0C-0405<br />011-0C-0410<br />011-0C-0416<br />011-0C-0434<br />011-0C-0441</p>
</blockquote> Bug #3609 (Resolved): subsampling typo? 11-C-309https://projects.ecoinformatics.org/ecoinfo/issues/36092008-11-08T00:13:01ZMichael Leemlee@nceas.ucsb.edu
<p>011-0C-0309 is listed in a way in the file that I think the 20% and 10% subsample should be something else, but I'm not sure what exactly. Probably requires a look at the original datasheet.</p> Bug #2918 (Resolved): Headers of entry forms are annoyinghttps://projects.ecoinformatics.org/ecoinfo/issues/29182007-08-29T22:06:00ZMichael Leemlee@nceas.ucsb.edu
<p>The header information disappears as you start a new row. Then, if you are on a new row and edit header info, you have to enter a species along with that. You should be able to just edit that info regardless of whether you are on a new row or not. Additionally, it should always show, even if no data yet on the plot.</p>
<p>This will require either a separate interface for dealing with updating values (hard), or a toggling of record source when on a new row to flip back to just entry_plots_*, but that means entering a species would have to flip it back.</p>
<p>No easy answer here, I'm afraid, and perhaps the best answer is to leave as it.</p> Bug #2722 (Resolved): Create datasets in viewerhttps://projects.ecoinformatics.org/ecoinfo/issues/27222007-01-13T21:25:00ZMichael Leemlee@nceas.ucsb.edu
<p>We want to keep being able to do the things we used to be able to do, but in the new archive database. This could be (probably SHOULD BE) another database on top of it that creates the analysis database and does other stuff.</p>
<p>The archive is just data. This way, it will be simpler to move the archive into PostgreSQL or MySQL or something else.</p> Bug #2666 (New): ready for DBA: Project 76 (Elizabeth City, NC): 52 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26662006-11-13T17:48:11ZMichael Leemlee@nceas.ucsb.edu
<p>this data needs to be processed and added to the (v2006) central archive<br />(Forbes writing:)</p>
<blockquote>
<p>For now, I would suggest that you use plots from Project 75 and 76 for error<br />checking. These plots have been "hand-checked" as precisely as possible<br />last week to avoid any major hang ups on your end.<br />They can be found at:</p>
<p>\\Bioark\peetlab\CVS\CVS_Projects\76_2006B-ElizabethCity\CVS_EEP_DataEntry_v<br />20_Project76</p>
</blockquote>