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 #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 #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 #2579 (Resolved): Default skin display is slightly broken on IEhttps://projects.ecoinformatics.org/ecoinfo/issues/25792006-10-27T21:03:15ZMatthew Perryperry@nceas.ucsb.edu
<p>The default skin has some cosmetic problems in Internet Explorer. The blue section header bars do not display properly (gaps appear between the corners and the center bar). This behavior applies to IE 5, 5.5, 6, and 7.</p>
<p>The knb skin appears to use a similar section header bar and it displays properly in IE. The solution will likely involved mimicking the knb skin.</p> 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 #2551 (Resolved): Generalized spatial xpaths for mutliple schemashttps://projects.ecoinformatics.org/ecoinfo/issues/25512006-09-11T22:16:43ZMatthew Perryperry@nceas.ucsb.edu
<p>The spatial harvester is currently generic enough to handle any xml document with west,east,north and south xpaths. These are configured in metacat.properties.</p>
<p>However, they are single values and thus a metacat instance can only support spatial options for one schema at a time.</p>
<p>We need to make this generic enough so that multiple supported schemas can be in the same database, their geographic coverages all represented in the spatial cache.</p> Bug #2550 (Resolved): Dateline and polar handling for pointshttps://projects.ecoinformatics.org/ecoinfo/issues/25502006-09-11T22:08:15ZMatthew Perryperry@nceas.ucsb.edu
<p>Unfortunately for cartographers the world is not flat. When a feature crosses the dateline or the polar regions, the cartesian coordinate system and all the assumptions that go with it are invalid. For instance the west bounding coordinate would be greater than the east bounding coordinate for a bounding box that crossed the international date line.</p>
<p>This is taken care of in the polygon code by splitting such polygons into multi-polygons.</p>
<p>We need to update the point centroid generation code to reflect this reality as well.</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 #2511 (Resolved): Include an optional spatial dataset packagehttps://projects.ecoinformatics.org/ecoinfo/issues/25112006-08-09T23:54:12ZMatthew Perryperry@nceas.ucsb.edu
<p>For users who can't rely on external WMS servers for their data, it would be nice to have some global datasets that they could store locally and use as a base map. The issue is size.. 32 MB for a world borders dataset of acceptable quality.</p>
<p>So we'll make this an optional data package that can be added on after the metacat install (For the CD distributiuons, we could incude it by default).</p>
<p>The trick will be configuring geoserver:</p>
<p>For the 1.7 release, we'll have to resort to an instruction set for how to edit the necessary config files. We should have the entries already constructed but commented out to make this as easy as possible.</p>
<p>For the 1.9 release, we should make this tightly integrated with the spatial admin page so that it is a few painless clicks. ( see bug 2180 and bug 2190 )</p> Bug #2469 (Resolved): DocumentImpl.buildIndex() does not index XPaths with attributes correctlyhttps://projects.ecoinformatics.org/ecoinfo/issues/24692006-06-22T22:15:32ZChris Jonescjones@nceas.ucsb.edu
<p>A 1.6.x metacat installation that indexes paths from the xml_nodes table into the xml_path_index table sets the xml_path_index.path column correctly, but sets the xml_path_index.nodedata incorrectly for ATTRIBUTE nodes. This results in searches that return an incorrect subset of documents because the xml_path_index table doesn't reflect the true values in xml_nodes.</p>
<p>For example, an EML 2.0.1 document with a packageId attribute:</p>
<p><eml:eml xmlns:eml="eml://ecoinformatics.org/eml-2.0.1" <br /> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br /> packageId="ALEXXX_015MTBD003R00_19990906.50.1" <br /> scope="system" system="knb" <br /> xsi:schemaLocation="eml://ecoinformatics.org/eml-2.0.1 eml.xsd"><br /> <dataset scope="document"><br /> <shortName>PISCO moored temperature, ALE</shortName></p>
<pre><code>... etc ...<br /> &lt;/dataset&gt;<br />&lt;/eml:eml&gt;</code></pre>
<p>will contain an indexed record in xml_path_index with the following columns:</p>
<p>docid: ALEXXX_015MTBD003R00_19990906.50 <br />path: /eml/@packageId <br />nodedata: PISCO moored temperature, ALE</p>
<p>rather than:</p>
<p>docid: ALEXXX_015MTBD003R00_19990906.50 <br />path: /eml/@packageId <br />nodedata: ALEXXX_015MTBD003R00_19990906.50.1</p>
<p>It seems that the nodedata for the attribute is set to the node value of the next leaf node, in this case the /eml:eml/dataset/shortName field.</p>
<p>This also occurs for other attributes that are indexed in the document, such as /eml:eml/dataset/coverage/geographicCoverage/@id (which has a value of 'ALE')</p>
<p>The above @id will have an indexed value set to the geographicDescription value found in /eml:eml/dataset/coverage/geographicCoverage/geographicDescription (not 'ALE' as above)</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 #2080 (Resolved): Admin should be able to modify a documenthttps://projects.ecoinformatics.org/ecoinfo/issues/20802005-05-16T22:42:37ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>Metacat administrators are able to delete documents created by other users. They<br />should be able to modify the document also.</p> Bug #1819 (Resolved): Access control - deny public/allow user read: user couldn't readhttps://projects.ecoinformatics.org/ecoinfo/issues/18192004-12-08T20:01:44ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>I created three DPs for which I had set the Access Permissions so the public<br />would be denied access and I (uid=connolly,o=NCEAS,dc=ecoinformatics,dc=org)<br />would be allowed to read. When I tried accessing the data from the KNB web site<br />(after I logged in as uid=connolly,o=NCEAS,dc=ecoinformatics,dc=org), I got a<br />message saying "User public does not have permission to read the document".</p>