InfoVeg: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362008-06-26T00:22:18ZEcoinformatics Redmine
Redmine Bug #3432 (New): Upgrade patching systemhttps://projects.ecoinformatics.org/ecoinfo/issues/34322008-06-26T00:22:18ZMichael Leemlee@nceas.ucsb.edu
<p>We need a better patching system, which is very basic at best. Currently you have to know about a patch (via the listserv) and download it from there. Would be a lot better if you asked it to check for updates, and it would download the list of available updates from CVS. Each update would have SQL that it would use to determine if the entry tool needed/could use the patch. If so, it would prompt you to download and apply it, but backup your database first.</p> Bug #2924 (New): Add "use defaults on this plot" for parties and place namehttps://projects.ecoinformatics.org/ecoinfo/issues/29242007-09-01T19:11:58ZMichael Leemlee@nceas.ucsb.edu
<p>There is an option to use default for parties and place names, but a message appears saying you can't do that yet.</p> Bug #2915 (New): Need to have rules for "odd" levels for data: planted stems >= level 3 and cove...https://projects.ecoinformatics.org/ecoinfo/issues/29152007-08-28T21:40:36ZMichael Leemlee@nceas.ucsb.edu
<p>Vigor is required. Its absence should be flagged by error checker as error.</p> Bug #2906 (New): DBA: reports could be improvedhttps://projects.ecoinformatics.org/ecoinfo/issues/29062007-08-17T18:32:47ZMichael Leemlee@nceas.ucsb.edu
<p>Would be nice to allow printing of full plots for plots that have some issue (a check box somewhere on the DBA form, perhaps) which would then change criteria to plotID in (select plotID from [somewhere] WHERE (the criteria));</p>
<p>ordering by plotID in the reports is problematic: this is order they were entered, not logical order. Should be switched to PTP.</p>
<p>duplText is not highlighted any colour on the report, which is odd. Should be yellowish and errors pink to draw attention to these locations when there are errors or duplicate messages.</p> Bug #2760 (New): add Quick fix for common errorshttps://projects.ecoinformatics.org/ecoinfo/issues/27602007-02-05T23:50:35ZMichael Leemlee@nceas.ucsb.edu
<p>need a quick fix for longitude is positive<br />also for filling in default of 10cm for minimum stem size.</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> Bug #2665 (New): Ready for DBA process: Project 75 (Singletary Lake, NC): 52 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26652006-11-13T17:47:21ZMichael 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, respectively at:</p>
<p>\\Bioark\peetlab\CVS\CVS_Projects\75_2006A-SingletaryLake\CVS_EEP_DataEntry_<br />v20_Proj75</p>
</blockquote> Bug #2663 (New): 2 errs left: + duplicates flagged: Project 73 (Mountain Bogs): 64 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26632006-11-13T17:46:29ZMichael Leemlee@nceas.ucsb.edu
<p>this data needs to be processed and added to the (v2006) central archive</p> Bug #2662 (New): Unfolding: Project 64 (Brunswick Co. NC): 88 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26622006-11-13T17:46:10ZMichael Leemlee@nceas.ucsb.edu
<p>this data needs to be processed and added to the (v2006) central archive</p> Bug #2661 (New): comments in XLS resolve: Project 63 (Francis Marion NF): 54 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26612006-11-13T17:45:48ZMichael Leemlee@nceas.ucsb.edu
<p>this data needs to be processed and added to the (v2006) central archive</p> Bug #2640 (New): Identify USDA species without county distribution where other spp in genus have ...https://projects.ecoinformatics.org/ecoinfo/issues/26402006-11-02T19:09:58ZRobert Peetpeet@unc.edu
<p>Look at PERSBOR s.s. with all those records for NC, SC, GA, AL that are<br />actually P. palustris. We need a solution.</p>
<p>1. Create a list of all the taxa that PLANTS reports for NC&SC with no county records but for which they do report county records for other taxa in the genus. Mike Lee should do this based on USDA data I have in hand. Once this is done, the process should be repeated for each of the states in the region.</p>
<p>2. Once we have the lists, Alan should examine the taxa and the USDA maps, and should create a list of taxa with too many records and a list of taxa with too few records. The final lists should be shared with USDA and BONAP. Highest priority should be to complete the NC&SC list.</p>
<p>3. These lists contain sets of taxa that should be treated as nominals rather than USDA/JK99 concepts. We should break the USDA taxa in our database into two groups with one = USDA concepts, and the second = nominal concepts. We can assign this step to Mike Lee. I will need to explain to Michael now to access the database in which the county occurrence data are stored.</p>
<p>4. As a separate and contingent bug, Xianhua should split USDA in the legend into into two labels and make any code changes necessary to support this split</p> Bug #2621 (New): 40. Concepts for CVS data?https://projects.ecoinformatics.org/ecoinfo/issues/26212006-10-27T23:01:51ZMichael Leemlee@nceas.ucsb.edu
<p>Add support of concepts to CVS data. In short, migrate from all CVS being Weakley concepts to explicit statement of concept where the concept can be any one in the formal list of accepted concepts. This might best be done by adding one column that corresponds to ConceptSource and which must [business rule] be a source mapped to Weakley in the relationships table. We will start by assuming that all current CVS concepts are Weakley concepts, but this will change soon.</p> Bug #2611 (New): Help function texthttps://projects.ecoinformatics.org/ecoinfo/issues/26112006-10-27T22:56:11ZMichael Leemlee@nceas.ucsb.edu
<p>Peet & Weakley need to add help options</p> Bug #2609 (New): Erroneous assignment of ambiguous statushttps://projects.ecoinformatics.org/ecoinfo/issues/26092006-10-27T22:53:49ZMichael Leemlee@nceas.ucsb.edu
<p>These last two issues are philosophical ones, rather than anything deriving from errors in the software or problems in the data.</p>
<p>If a user enters a search for an infraspecific taxon that we recognize, a map is displayed with records for that taxon, along with any records determined to the species level for the “parent†species. The species-level records, however, are marked as having an ambiguous identification. This way of distinguishing the species-level records seems valuable and important to me, as long they are to be included in response to an infraspecific taxon search.</p>
<p>In contrast, if a user enters a search for a species which has recognized infraspecific taxa, the software thoughtfully displays a list with the species and the infraspecific taxa, requiring the user to choose among them in order to continue. Should the user select the species, the resulting map shows both species level records and appropriate infraspecific taxon records. The species level records, however, are marked on the map as ambiguous. Displaying the results in this way I think is not consistent with the search the user performed in this case. When the search requested, and the concept illustrated by a map, is a species, it seems most appropriate to me to treat records identified to the species level as not ambiguous, and to display them as not ambiguous. This can be explored by searching on Acer rubrum, and A. rubrum var. rubrum.</p> Bug #2587 (New): Inability to search on taxa not treated by Weakleyhttps://projects.ecoinformatics.org/ecoinfo/issues/25872006-10-27T22:37:15ZMichael Leemlee@nceas.ucsb.edu
<p>At least some taxa treated as current in Specify do not show up when using the SE Flora search functions. For example, a search on Dicerandra cornutissima yields no results although the name is recognized in Specify and there are specimens records (type specimens from Florida) entered for this species. (D. cornutissima does not appear as a synonym in Weakley, perhaps because it is out of the geographic range of the Flora. Might this be a general problem for taxa that do not occur within the range of the Weakley Flora?)</p>
<p>RKP:<br />I think we are clear in the documentation on the website that “Taxa recognized in this treatment follow Weakley 2006 (available from <a class="external" href="http://herbarium.unc.edu/flora.htm">http://herbarium.unc.edu/flora.htm</a> ).†This means that we do not support any other taxa. This was an executive decision made by Peet & Weakley that could be changed. However, reversal of this decision will require we implement a bunch of business rules that are not in place, and might require some concept mapping that has not yet been initiated. An elegant change might be nice, but would not be easy. A hack change might be to search for taxon names present in Specify but not in Weakley, and map those on a raw basis, without any concept mapping and with a caveat displayed for user caution.</p>