Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362007-03-21T18:09:38ZEcoinformatics Redmine
Redmine Bug #2805 (Resolved): Metacat Performance: updates from Morpho of data packages are taking longer...https://projects.ecoinformatics.org/ecoinfo/issues/28052007-03-21T18:09:38ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>When a data set is saved online it is a quick process. However, when it is saved or updated using Morpho it can take longer than five minutes. Recent documents have all been created using the online NCEAS Data Repository form. When they need to be updated using Morpho the save to the network process takes longer than five minutes. I've recored some saves (updates) of up to ten minutes.</p>
<p>Callie</p> Bug #2748 (Resolved): MetaCatServlet.handleUploadAction() can cause data file deletion in the dat...https://projects.ecoinformatics.org/ecoinfo/issues/27482007-01-25T19:42:43ZChris Jonescjones@nceas.ucsb.edu
<p>During the upload of data documents to Metacat 1.6.x, data documents that have been previously uploaded can be deleted from Metacat's file storage area when the same file is uploaded on a second attempt. In MetaCatServlet.handleUploadAction(), DocumentImpl.registerDocument() is called after the data file has been created in the filesystem. If for some reason registerDocument() throws an exception (for instance if the docid and revision is already taken), then the data file is deleted, regardless of whether or not it happened in a previous transaction.</p>
<p>This can be critical since an entire Metcat data store could be deleted by calling action=upload on the existing data docids residing in the catalog. The existence of the data files remains registered in the catalog tables, but the file will be physically gone from the data store.</p> Bug #2691 (Resolved): Update knbweb module to use maphttps://projects.ecoinformatics.org/ecoinfo/issues/26912006-12-07T00:31:18ZMatthew Perryperry@nceas.ucsb.edu
<p>The knbweb module needs to be integrated with our mapbuilder interface.</p> Bug #2689 (Resolved): Upgrade to Geoserver 1.4https://projects.ecoinformatics.org/ecoinfo/issues/26892006-12-07T00:27:42ZMatthew Perryperry@nceas.ucsb.edu
<p>The current (12/06/2006) cvs head uses an early beta of geoserver 1.4. Though it works flawlessly for our purposes, it would be best to upgrade to geoserver 1.4 final to resolve any outstanding bugs and make it easier to upgrade in the future and support.</p> Bug #2670 (Resolved): Test Metacat version with updates does not link to the "create a new accoun...https://projects.ecoinformatics.org/ecoinfo/issues/26702006-11-14T21:48:26ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>This is not a bug for the production version of Metacat(1.6.0). The "Head" version of Metacat does not links to the form page where a user can create a new account. The productions server goes to this location:</p>
<p><a class="external" href="http://knb.ecoinformatics.org/cgi-bin/ldapweb.cgi?cfg=knb">http://knb.ecoinformatics.org/cgi-bin/ldapweb.cgi?cfg=knb</a></p>
<p>The test server does not link to the form. I only get the top of the page without the form. It has the "Register for the Knowledge Network for Biocomplexity (KNB)!" title and informaion but no form.</p>
<p>On the test Metacat server the link from the KNB homepage that says create a new account goes to <a class="external" href="http://ldap.ecoinformatics.org/cgi-bin/ldapweb.cgi">http://ldap.ecoinformatics.org/cgi-bin/ldapweb.cgi</a>. This does not work.</p>
<p>On the production server the link goes to: <a class="external" href="http://knb.ecoinformatics.org/cgi-bin/ldapweb.cgi?cfg=knb">http://knb.ecoinformatics.org/cgi-bin/ldapweb.cgi?cfg=knb</a> . This works.</p> Bug #2669 (Resolved): Mapbuilder incompatible w/ Safari, Operahttps://projects.ecoinformatics.org/ecoinfo/issues/26692006-11-14T19:48:00ZMatthew Perryperry@nceas.ucsb.edu
<p>Mapbuilder, our current web mapping client, uses the browser to do XSLT transforms on the client side. A number of browsers do not allow XSLT to be accessed from javascript, most notably Safari, Opera and Konqueror.</p>
<p>See <a class="external" href="http://developer.apple.com/internet/safari/faq.html#anchor21">http://developer.apple.com/internet/safari/faq.html#anchor21</a></p>
<p>This is a fundamental problem and the mapbuilder developers have stated that they have no plans to support browsers without javascript XSLT.</p>
<p>We have two options to remedy this:</p>
<p>- Switch to a different web mapping client<br />- Detect the browser and alert the user when their browser is not compatible (and don't display the broken map of course).</p> Bug #2648 (Resolved): Update broken LTER link in web templateshttps://projects.ecoinformatics.org/ecoinfo/issues/26482006-11-07T23:17:29ZDuane Costadcosta@lternet.edu
<p>All instances of the following LTER link in metacat's web templates:</p>
<pre><code><a class="external" href="http://sql.lternet.edu/scripts/intranet/sendmemypassword.pl">http://sql.lternet.edu/scripts/intranet/sendmemypassword.pl</a></code></pre>
<p>should be replaced by the following link:</p>
<pre><code><a class="external" href="http://savanna.lternet.edu/sendpassword.php">http://savanna.lternet.edu/sendpassword.php</a></code></pre> Bug #2554 (Resolved): Store the spatial data cache outside servlet contexthttps://projects.ecoinformatics.org/ecoinfo/issues/25542006-09-13T19:33:41ZMatthew Perryperry@nceas.ucsb.edu
<p>Currently the spatial data cache is stored within the servlet context. Geoserver's configuration hardcodes the shapefile path so storing it within the context allows you to specify relative paths in the geoserver config files. However, if you reinstall metacat, the cache will be replaced and will need to be regenerated on every "ant install". This is obviously a problem for developers who might rebuild frequently.</p>
<p>The proposed solution involves configuring the shp paths in build.properties and updating the geoserver config files at build-time. Doing this with ant tokens would be straighforward but we'd ideally want another solution (XML-DOM based since all geoserver configuration files are xml).</p>
<p>The paths would also need to be in metacat.properties so they could be accessed by the spatial harvester class.</p> Bug #2552 (Resolved): Spatial query class to use geotools against the spatial cachehttps://projects.ecoinformatics.org/ecoinfo/issues/25522006-09-11T22:22:19ZMatthew Perryperry@nceas.ucsb.edu
<p>Currently the spatial query is run with a standard metacat squery. Besides being inefficient, it is also inaccurate since it doesn't take into account some fundamental quirks in spatial relationships (the international dateline, multiple polygons representing the same feature, odd shaped polygons or holes).</p>
<p>The idea would be to write a class that, given a spatial query (bbox or point) would use geotools to query the actual spatial cache and return a list of matching docids.</p> Bug #2549 (Resolved): Limit spatial cache to public documentshttps://projects.ecoinformatics.org/ecoinfo/issues/25492006-09-11T22:02:20ZMatthew Perryperry@nceas.ucsb.edu
<p>Until we implement a feasible wms feature filter ( bug 2548 ) we must only put publically readable documents in the spatial cache.</p> Bug #2505 (Resolved): Spatial query errors with multiple geographic coverageshttps://projects.ecoinformatics.org/ecoinfo/issues/25052006-07-31T22:19:39ZMatthew Perryperry@nceas.ucsb.edu
<p>The current spatial query logic (in the servlet action=spatial_query OR in the advancedSearch) does not properly account for documents containing muliple geographic coverages. It simply checks your search box against the xmlpath for northBoundingCoordinate, south, etc. So queries are actually being run against the bounding box of all bounding boxes. The result is that you may be getting false postives.</p>
<p>For example, lets say we have a document with a geographic coverage in northern Maine AND southern California. Someone performs a spatial query around Kansas and this document will show in the results.</p>
<p>In order to perform the proper query, we'll have to compare the spatial search box against EACH of the geographic coverages in a document. My understanding is that we'll need a way to differentiate, based on the xml path, between different geographicCoverages ?</p> Bug #2499 (Resolved): Port spatial harvesting script from C++ to javahttps://projects.ecoinformatics.org/ecoinfo/issues/24992006-07-24T21:19:44ZMatthew Perryperry@nceas.ucsb.edu
<p>The current way to represent the metacat EML documents in a spatial dataset relies on saving the information to a temporary text file then calling a compiled C++/Shapelib application to generate a shapefile.</p>
<p>Since we are using Geoserver and the associated Geotools data library, this functionality can be handled entirely in java without the need for compiling binaries or external dependencies.</p> Bug #2377 (Resolved): No Default Namespace in Recordshttps://projects.ecoinformatics.org/ecoinfo/issues/23772006-03-02T23:12:43ZDavid Sledgedsledge@lternet.edu
<p>Looking at this record in metacat in XML, I noticed that only the root element<br />has a prefix ("eml:"), and that there isn’t a default namespace URI declared for<br />elements without prefixes. I’ve looked at a few other records, and so far they<br />all follow the same pattern.</p>
<p>I tried to see if the records would validate against the eml*.xsd files despite<br />not having prefixes, but then I ran into bug 2054<br />(<a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2054">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2054</a>).</p> Bug #2189 (Resolved): Refactor skins so returnfield list comes from configurationhttps://projects.ecoinformatics.org/ecoinfo/issues/21892005-09-06T17:12:17ZJohn Harrisharris@nceas.ucsb.edu
<p>Refactor skins so returnfield list comes from cfg, so then both metacat and<br />mapserver can use this info to generate query, mapserver creates XML resultset<br />then uses XSLT to create result list.</p> Bug #2183 (Resolved): use metacat events to trigger spatial element creationhttps://projects.ecoinformatics.org/ecoinfo/issues/21832005-09-06T16:53:07ZJohn Harrisharris@nceas.ucsb.edu
<p>Currently, the creation of spatial elements used within the Metacat spatial<br />viewer is done through a call to an external harvester via a cron job. This<br />needs to change to a workflow that includes the creation of spatial elements<br />during metacat (insertion, update, deletion) transactions. Moreover, these<br />elements need to be more tightly coupled with Metacat (eg, Metacat needs to have<br />knowledge of the various elements stored and how these elements correspond to<br />data and metdata within Metacat).</p>