Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362011-09-19T22:12:03ZEcoinformatics Redmine
Redmine VegBank - Bug #5493 (In Progress): tomcat crashes frequentlyhttps://projects.ecoinformatics.org/ecoinfo/issues/54932011-09-19T22:12:03ZNick Brandbrand@nceas.ucsb.edu
<p>Tomcat frequently gets into a state where it stops serving pages and needs to be restarted. This has been happening for a while now, first on the RHEL4 server (vegbank), and now on the new Ubuntu 10.04 virtual server (vegbankvm).</p>
<p>Most recently the tomcat service has been manually restarted on 7/30, 8/19, 8/21, 8/27, and 9/19.</p>
<p>I attempted to stop the frequent crashing by increasing the allocated memory in tomcat from 2GB to 4GB, but it crashed a couple days after the change, so I restored the 2GB setting.</p> VegBank - Bug #5478 (New): after querying plants, communities, or plots, link back to searchhttps://projects.ecoinformatics.org/ecoinfo/issues/54782011-08-30T01:28:18ZMichael Leemlee@nceas.ucsb.edu
<p>When searching for something, web sites often want you to be able to modify your search terms easily and search again. We should do that. Now, you have to use the back button.</p>
<p>Seems like we could include part of the search page (fancy option) or at least offer a backlink to it, with the form filled out, ideally.</p> VegBank - Bug #5391 (New): build process into war file does not generate faq.htmlhttps://projects.ecoinformatics.org/ecoinfo/issues/53912011-05-04T20:38:40ZMichael Leemlee@nceas.ucsb.edu
<p>the initial build process that generated the war file did not generate a faq.html file in web/general. This is handled in web/build.xml and needs to be called.</p> InfoVeg - Bug #5388 (New): Migrate CF projects to Archive DBhttps://projects.ecoinformatics.org/ecoinfo/issues/53882011-04-29T16:00:04ZForbes Boylemboyle@unc.edu
<p>CF projects need to be QC'd and migrated.</p> InfoVeg - Bug #5384 (New): Collections spreadsheets verificationhttps://projects.ecoinformatics.org/ecoinfo/issues/53842011-04-29T15:40:29ZForbes Boylemboyle@unc.edu
<p>We want to be able to browse for a collection spreadsheet and determine what percentage of the updated specimens are integrated into the Analysis DB.</p> InfoVeg - Bug #5383 (New): Updating GUIDs for taxon observationshttps://projects.ecoinformatics.org/ecoinfo/issues/53832011-04-29T15:38:56ZForbes Boylemboyle@unc.edu
<p>This will allow better annotation and updating of our taxa, says MLee. Will also help upgrade to Weakley 2010.</p> VegBank - Bug #5211 (New): Colorado data not entered correctlyhttps://projects.ecoinformatics.org/ecoinfo/issues/52112010-10-20T13:17:10ZMichael Leemlee@nceas.ucsb.edu
<p>The taxonomy was not updated as originally requested, there are some problems with the cover values, there are some problems with the metadata, and the community names assigned are strangely rendered.</p>
<p>(from Peet email 10/20/2010)</p> InfoVeg - Bug #5159 (New): auto filter for sensitive specieshttps://projects.ecoinformatics.org/ecoinfo/issues/51592010-08-21T21:36:13ZMichael Leemlee@nceas.ucsb.edu
<p>Today (Sept 3, 2009), Alan and I [Michael] had a productive conversation about how and for<br />which species we should fuzz plot locations. I described our current<br />approach, which rounds plot locations to the nearest 0.01 degree for<br />Lat and Long to approximate a 1km fuzzing, 0.1 degree for 10km fuzzing<br />and 1 degree for 100km fuzzing. Alan asked a great question as to<br />what radius this resulted in. It yields the centroid of a 0.01, 0.1,<br />or 1 degree box, which amounts to a DIAMETER of a little less than the<br />1km, 10km, and 100km.</p>
<p>I ran a quick algorithm for all plots in our database and found that<br />if we say we are fuzzing 100 km (1 degree), the average distance from<br />those points to our plots is 34.7km. If we are trying for 10km (0.1<br />deg), we get 3.7km. If we try to 1km (0.01 deg), we get 380m. We<br />would expect a smaller number than what we are aiming for, but clearly<br />these are a bit low.</p>
<p>So we probably should either round to the nearest 0.02, 0.2, and 2<br />degree boxes, or actually write an algorithm that will pick a point at<br />random within the specified radius. I don't think that should be too<br />hard.</p>
<p>Next, and the key item, Alan said that he didn't think all rare<br />species should be fuzzed. There are plenty that have no economical<br />value, are not of interest to poachers, and are difficult to get to in<br />any case. He said that the key ones to block are Panax, some orchids,<br />some lillies, carniverous species except Utricularia. I'm probably<br />missing some. Also we need to fuzz locations for all bogs plots given<br />the possible existence of bog turtles there, though those don't turn<br />up in our data. I have fuzzed all of Brenda's bog plots in project 73<br />already in the community summary pages. Alan said he could come up<br />with a list of species for us without taking too much effort, as well<br />as an appropriate fuzzing. He expressed a desire to fuzz more than<br />10km but less than 100km, which we might want to consider, as well.</p> InfoVeg - Bug #5105 (In Progress): have x- specimens maphttps://projects.ecoinformatics.org/ecoinfo/issues/51052010-07-28T17:36:55ZMichael Leemlee@nceas.ucsb.edu
<p>example X-UNCC, X-WNC, etc.</p>
<p>reported by Carol Ann</p> VegBank - Bug #4796 (New): receipt of plots with accession codes after loadinghttps://projects.ecoinformatics.org/ecoinfo/issues/47962010-02-16T16:49:37ZMichael Leemlee@nceas.ucsb.edu
<p>Don says: Would it be possible in the future, that whenever someone uploaded their data into VegBank, they could somehow be sent a table of their own plot codes and the VegBank accession code?</p>
<p>Michael: we could certainly add this to the receipt.</p> VegBank - Bug #4494 (New): Tracking and correlating multiple database GUIDs to entitieshttps://projects.ecoinformatics.org/ecoinfo/issues/44942009-10-22T19:16:08ZMichael Leemlee@nceas.ucsb.edu
<p>Some mechanism needed to track GUIDs from other dbs and how they relate to VB entities will eventually be needed. Need mechnism to discover identical plots in distributed databases, ideally, otherwise allow users to copy and paste lists of equivalent GUIDs</p>
<p>Source is section 2.6.10 number 39 of requirements document, page 76</p> InfoVeg - Bug #4378 (New): Classification Automation Toolshttps://projects.ecoinformatics.org/ecoinfo/issues/43782009-09-10T18:41:54ZMichael Leemlee@nceas.ucsb.edu
<p>1) Assess classification of current plots based on composition<br /> a) distance metrics to centroid as start<br /> b) flag suspect plots (far from centroid) and then allow flag to be marked OK (perhaps with date)</p>
<p>2) For new plots, suggest potential candidate communities</p>
<p>3) ADD primary classification field<br /> a) we aim to have a primary classification for each plot</p>
<p>4) method detail:<br /> a) eliminate all species not to species level<br /> b) dumb down all varieties to species level <br /> c) eliminate composite species and dumb down composite vars<br /> d) provide an analysis of all eliminated species with 10% or more cover (Forbes may adjust rules when considering this)</p> InfoVeg - 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> InfoVeg - Bug #3532 (In Progress): Revise elevation based on NASA datahttps://projects.ecoinformatics.org/ecoinfo/issues/35322008-10-16T16:58:36ZMichael Leemlee@nceas.ucsb.edu
<p>five things:<br />1) get elevation data from Jenn for our plots (Forbes)<br />2) check elevations and flag any that are significantly different (raw difference + percent different, i.e. 0-50 is flagged differently than 1000-1050).<br />3) check flagged elevations and decide on a value<br />4) apply new elevation values to database<br />5) provide Lee Anne with a copy of new elevation data.</p> InfoVeg - Bug #3010 (In Progress): Should encode strings in URL requesting mapping of plotshttps://projects.ecoinformatics.org/ecoinfo/issues/30102007-11-23T18:38:33ZMichael Leemlee@nceas.ucsb.edu
<p>Here's some help for characters that need encoding:<br /><a class="external" href="http://www.blooberry.com/indexdot/html/topics/urlencoding.htm">http://www.blooberry.com/indexdot/html/topics/urlencoding.htm</a></p>