Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362012-05-22T21:50:39ZEcoinformatics Redmine
Redmine Kepler - Bug #5611 (New): LinearModel actor doesn't handle input variables properlyhttps://projects.ecoinformatics.org/ecoinfo/issues/56112012-05-22T21:50:39ZJim Regetzregetz@nceas.ucsb.edu
<p>The R code in the RExpression-based LinearModel actor has several problems:<br />1. In a linear model, it's the <em>independent</em> (predictor) variables that can be either numeric or factor (categorical). The dependent (response) variable must be numeric. The actor code gets this reversed, and fails with an error depending on the inputs.<br />2. The conditional is.character() in the final 'if' statement always evaluates to FALSE because of the conversion-to-factor in the first 'if' statement.<br />3. The intercept and slope aren't reported out in any useful way, and the intercept isn't even printed to the console output (if displayed).</p>
<p>I'd suggest the following replacement, which doesn't conform exactly to the intended behavior of the original actor, but I think provides a nice starter template for doing a univariate linear model fit. I also changed it to emit the fitted model object itself, which could be passed to another actor for summarizing, generating an ANOVA table, extracting coefficient estimates, etc.</p>
<p>Note that I wouldn't usually explicitly store the model formula as an object, but here I think it's useful to indicate the mapping of input ports to model variables right at the top.</p>
<p>#--------------------------------------------------<br />model <- Dependent ~ Independent</p>
<p>if (is.character(Independent)) {<br /> Independent <- factor(Independent)<br />}</p>
<ol>
<li>fit model; fitted lm object is available on output port<br />results <- lm(model)<br />print(summary(results))</li>
</ol>
<ol>
<li>plot data, adding regression line if appropriate<br />plot(model)<br />if (is.numeric(Independent)) {<br /> abline(results, col="red")<br />}<br />#--------------------------------------------------</li>
</ol> Morpho - Bug #5058 (Resolved): Access wizard mishandles certain combinations of allow/deny elementshttps://projects.ecoinformatics.org/ecoinfo/issues/50582010-06-25T00:40:08ZJim Regetzregetz@nceas.ucsb.edu
<p>Morpho substrings XPaths improperly in certain cases when extracting data for the Access wizard, ultimately causing it to unnecessarily punt to the tree editor.</p>
<p>Here are some reproducible cases:</p>
<ul>
<li>If there is an 'allow' element for principal 'public', along with 10 or more 'allow' elements for (non-public) principals, Morpho incorrectly parses the 10th one.</li>
<li>If there is an 'allow' element for principal 'public', Morpho incorrectly parses any 'deny' elements for (non-public) principals.</li>
<li>If there is a 'deny' element for principal 'public', along with at least one 'allow' element and at least one 'deny' element for (non-public) principals, Morpho incorrectly parses those 'deny' elements.</li>
</ul>
<p>For a live example of the first case, try to open the Documentation->Access Information interface for this data package:<br /><a class="external" href="http://knb.ecoinformatics.org/knb/metacat/krobinson.12.6/nceas">http://knb.ecoinformatics.org/knb/metacat/krobinson.12.6/nceas</a></p>
<p>I believe the problem lies at least partly in lines 1304-1305 of AccessPage.java (as of rev 4925). For the cases above, this.xPathRoot.length() isn't actually the right value to pass to the substring statement. Depending on the case, the trimmed XPath ends up either having an extra character at the start, or having its first character truncated.</p>
<p>From stderr.log, here's an example of the first case above (note the extra ']' as the first character of the trimmed nextXPaths):</p>
<p>...<br />Access: nextXPath = /access/allow<sup><a href="#fn10">10</a></sup>/principal<sup><a href="#fn1">1</a></sup><br /> nextVal = user10<br />Access: TRIMMED nextXPath = ]/principal<sup><a href="#fn1">1</a></sup><br />Access: nextXPath = /access/allow<sup><a href="#fn10">10</a></sup>/permission<sup><a href="#fn1">1</a></sup><br /> nextVal = read<br />Access: TRIMMED nextXPath = ]/permission<sup><a href="#fn1">1</a></sup><br />...</p>
<p>And here's an example of the second case (note the missing first letter in the trimmed nextXPaths -- actually, maybe they're missing a leading '/' too?):</p>
<p>...<br />Access: nextXPath = /access/deny<sup><a href="#fn1">1</a></sup>/principal<sup><a href="#fn1">1</a></sup><br /> nextVal = user09<br />Access: TRIMMED nextXPath = rincipal<sup><a href="#fn1">1</a></sup><br />Access: nextXPath = /access/deny<sup><a href="#fn1">1</a></sup>/permission<sup><a href="#fn1">1</a></sup><br /> nextVal = read<br />Access: TRIMMED nextXPath = ermission<sup><a href="#fn1">1</a></sup><br />...</p> Morpho - Bug #5046 (Resolved): wrong text label for attributeOrientation in xslhttps://projects.ecoinformatics.org/ecoinfo/issues/50462010-06-10T16:47:33ZJim Regetzregetz@nceas.ucsb.edu
<p>Open jscientist.7.2 in Morpho and look at the entity metadata panel on the right. Under Physical Structure Description, it says that the Maximum Record Length is 'column', but column is actually the attributeOrientation.</p>
<p>Looks like this was a copy-and-paste error in the eml-physical-*.xsl files (all versions back to EML 2.0.0). The HTML text is "Maximum Record Length" inside two different xls:templates: one that matches maxRecordLength, and one that matches attributeOrientation. In the second case, the text should probably read "Attribute Orientation" instead.</p> Morpho - Bug #4975 (Resolved): Morpho can't handle docid prefix containing a periodhttps://projects.ecoinformatics.org/ecoinfo/issues/49752010-05-04T16:53:07ZJim Regetzregetz@nceas.ucsb.edu
<p>A user just reported mysterious problems attempting to save and reopen documents in Morpho. It appears the problem is that her prefix contains a period, impairing Morpho's ability to parse the document id.</p>
Steps to reproduce:
<ul>
<li>Create a new profile, choosing a prefix that contains a period (foo.bar)</li>
<li>Create a new data package, and save locally</li>
<li>Restart Morpho</li>
</ul>
<p>The saved package doesn't appear in the Open Data Package window.</p>
<p>Also, .morpho/profiles/foo.bar/data looks like this:<br />`-- foo<br /> `-- bar.3.1</p>
<p>Rather than this:<br />`-- foo.bar<br /> `-- 3.1</p>
<p>Either Morpho needs to be smarter about parsing IDs, or if such a prefix is illegal, it shouldn't allow users to create one containing periods in the first place (and this should be documented).</p> Metacat - Bug #4862 (Closed): NCEAS registry form now creates access rules for extra partieshttps://projects.ecoinformatics.org/ecoinfo/issues/48622010-03-02T22:11:28ZJim Regetzregetz@nceas.ucsb.edu
<p>In the past, EML documents created using the NCEAS registry form were written with the following automatic access rules:</p>
<p>ALLOW: [all] uid=nceasadmin,o=NCEAS,dc=ecoinformatics,dc=org<br />ALLOW: [read][write] [...dn of document submitter...]<br />ALLOW: [read] public</p>
<p>However, as of approx March 2009, it looks like the following extra access rules are also being added:</p>
<p>ALLOW: [all] cn=knb-prod,o=NCEAS,dc=ecoinformatics,dc=org<br />ALLOW: [all] cn=esa-moderators,dc=ecoinformatics,dc=org</p>
<p>This doesn't seem right. My guess is that the NCEAS registry has been polluted by rules that are supposed to apply to other registries?</p>
<p>AFAICT, the most recent package created with the original access rules is nceas.955.1, submitted on 26-Feb-2009. The first package created with the extra rules is nceas.956.1, submitted on 31-Mar-2009. Presumably a change was made sometime in between those dates.</p> Morpho - Bug #4640 (New): add prev/next buttons to 'Edit Column Documentation' dialoghttps://projects.ecoinformatics.org/ecoinfo/issues/46402009-12-19T00:59:59ZJim Regetzregetz@nceas.ucsb.edu
<p>When a user needs to edit the documentation of several columns in one sitting, it is tedious to have to open and close the Edit Column Documentation dialog separately for each column. This often takes more time than the actual edit itself. This could be solved by adding "prev" and "next" buttons for moving back and forth across columns (and making multiple edits) within a single instance of the Edit Column Documentation dialog.</p>
<p>Note that the Import Data table wizard already has buttons to go back and forth across columns, albeit with extra things at the beginning and end of the wizard.</p> Morpho - Bug #4636 (Resolved): Morpho should ignore commas inside double-quoted fields (CSV import)https://projects.ecoinformatics.org/ecoinfo/issues/46362009-12-15T22:40:49ZJim Regetzregetz@nceas.ucsb.edu
<p>It is a standard CSV convention to enclose fields containing commas (i.e., commas that do not represent delimiters) in double quotes. Most applications respect this convention. However, when importing or displaying a comma-separated data file, Morpho treats all commas as field separators regardless of double quotes. This means the automatic import wizard doesn't behave properly, and data are misaligned in the data panel viewer.</p>
<p>A workaround is to convert the CSV file to another format (e.g., tab-delimited) before importing, but this is not always convenient nor desirable.</p>
<p>Sample CSV file attached.</p> Morpho - Bug #4635 (Resolved): morpho attempts to display binary otherEntity objects as texthttps://projects.ecoinformatics.org/ecoinfo/issues/46352009-12-15T19:27:43ZJim Regetzregetz@nceas.ucsb.edu
<p>Morpho attempts to display otherEntity objects as text in the data table panel, even when they are binary files. Not only does this result in gibberish being displayed, but it can take a few seconds or longer if the file is large.</p>
<p>Two example DPs on KNB (note revision numbers):<br />nceas.958.1 -- contains an Excel file<br />nceas.960.1 -- contains a PDF file</p> Morpho - Bug #4621 (New): Allow sets of codes/definitions to be reused across data packageshttps://projects.ecoinformatics.org/ecoinfo/issues/46212009-12-10T23:21:24ZJim Regetzregetz@nceas.ucsb.edu
<p>Morpho allows enumerated value codes/definitions to be "imported from another table", although "imported" is somewhat of a misnomer because they are simply documented by reference (i.e., via entityCodeList in EML), and this only works within a single DP. This feature does <strong>not</strong> directly address the common use case of wanting to reuse identical (or similar) enumerated domains for different attributes, especially across DPs.</p>
<p>One approach might be to allow code/definition sets to be imported (copied) from <strong>any</strong> documented enumeratedDomain field that contains codeDefinitions, in any locally saved DP. This would require a GUI element to allow the user to select the desired DP, data table, and attribute to import from.</p>
<p>A second approach might be to provide a mechanism for users to save any existing code/definition sets to a local "registry" (in their morpho cache), and then import only from that code/definition registry. This would require a GUI element for saving (and probably naming) the codes/definitions from within the column documentation editor for enumerated domain attributes, and some modification of what the existing import button does.</p>
<p>After import, the codes/definitions should be editable for tweaking.</p>
<p>The general motivations for this bug are similar to those expressed for other forms of templating, namely in bug 1532 (for data packages) and bug 2851 (for attributes).</p> Morpho - Bug #4620 (Resolved): Add handler for externally saving/opening an attached data objecthttps://projects.ecoinformatics.org/ecoinfo/issues/46202009-12-10T18:45:02ZJim Regetzregetz@nceas.ucsb.edu
<p>Imagine someone wants to quickly inspect the contents of a binary data file attached to a data package. Currently, the only way to do so is to export the entire DP, then drill down through cryptically named directories in the exported directory tree to manually locate and open the file. There should be a more straightforward way within Morpho to externally save or open a specific attached data object.</p>
<p>For the user, this should behave much like handling an email attachment: e.g., provide some sort of GUI element (button or menu option) that triggers a pop-up dialog presenting the option of saving the data object to disk or opening it with some other application. Note that the Metacat web registry already provides this functionality by presenting a "Download File" link for each attached entity in the DP, and allowing the web browser to handle the rest.</p>
<p>Ideally this functionality would apply not just to data tables, but also to other entity types (especially otherEntity).</p>
<p>Note: The button or menu text should probably be more along the lines of "export data" rather than "open data", otherwise users may be misled into thinking that editing/saving the object in the external application will actually save it within the DP.</p> Morpho - Bug #4106 (Resolved): Add Cancel button to dialog for closing unsaved packagehttps://projects.ecoinformatics.org/ecoinfo/issues/41062009-05-22T22:21:44ZJim Regetzregetz@nceas.ucsb.edu
<p>Closing an unsaved data package (or exiting Morpho when unsaved DPs are open) produces a dialog that only offers two options: save the DP, or close it without saving. A Cancel button should be added to allow users to go back to editing the DP if they change their mind or had accidentally closed the DP before they were ready.</p>
<p>I'm calling this an enhancement, but think it's pretty important. Currently, users can find themselves forced to choose between saving unwanted/incomplete changes or discarding desired changes (this has happened to me).</p> Morpho - Bug #4099 (New): In map viewer, provide reset button for zoom and coordinateshttps://projects.ecoinformatics.org/ecoinfo/issues/40992009-05-21T17:13:04ZJim Regetzregetz@nceas.ucsb.edu
<p>A "Reset zoom" button would be useful in all map viewer panels (spatial search and geographic coverage editor). Perhaps even better would be a "Reset selection" button that simultaneously resets the zoom level to global AND resets the coordinates to their default values. Currently the only way to reset zoom is hit the "Zoom Out" button repeatedly, and the only way to reset the coordinates is to cancel the entire dialog and start again.</p> Morpho - Bug #4098 (New): Cancelling map viewer should reset zoomhttps://projects.ecoinformatics.org/ecoinfo/issues/40982009-05-21T17:03:44ZJim Regetzregetz@nceas.ucsb.edu
<p>This applies to the map viewer that appears both for Spatial Search and for editing Geographic Coverage metadata. If you change spatial zoom, then cancel the dialog, IMHO the zoom should be reset to global the next time you open it. Currently this doesn't happen. Note if you change any of the coordinates, they <strong>are</strong> reset after you cancel the dialog, and this seems like the correct behavior to me.</p> Morpho - Bug #4096 (New): Must click tab twice to display metadata for table without read accesshttps://projects.ecoinformatics.org/ecoinfo/issues/40962009-05-21T01:44:09ZJim Regetzregetz@nceas.ucsb.edu
<p>This happens for me with a data package that has several publicly readable data tables, plus an additional table for which I don't have read access. When I click on the tab of the private table, Morpho gives two warning windows. After dismissing these, the table documentation shows the metadata for the first table in the DP, <strong>not</strong> the table I clicked on. After dismissing the warnings, I have to click the tab a second time to make the correct documentation for this table appear.</p>
<p>I see this with Morpho 1.7.0-RC3 on both Ubuntu 8.04 and Windows XP. However, on Mac OS X, the correct table documentation appears after the first click.</p> Kepler - Bug #3785 (New): Unclear Java requirements for Kepler installer on Vista 64-bithttps://projects.ecoinformatics.org/ecoinfo/issues/37852009-01-29T18:09:45ZJim Regetzregetz@nceas.ucsb.edu
<p>On a Vista 64-bit machine, the Kepler 1.0.0 installer for Windows failed with 64-bit JRE 5.0 (Update 16) installed, reporting the error "Cannot find Java 1.5.0". Adding the correct Java bin directory to the path variable didn't make a difference, nor did running the installer as administrator, nor did running it in compatibility mode for XP.</p>
<p>After I closed the installer error window, a web browser window automatically opened at the Sun download page for (32-bit) Java 6 -- not 1.5.x, as the Kepler documentation suggests. Nevertheless, after I installed this, Kepler installation proceeded normally, and Kepler itself seemed to work (superficially at least). Subsequent experimentation indicated that installing 32-bit Java 1.5 also works, as documented.</p>
<p>Is the Kepler installer simply having problems finding the 64-bit Java binaries, or is 32-bit Java actually required? In either case, it would be helpful if the Kepler documentation provided more clarity on the matter, ideally with a note included on (or directly linked to) the downloads page. It is also confusing that the installer error complains about missing Java 1.5.0, but the user is prompted to install Java 6 (in conflict with the documentation).</p>