Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362006-07-31T22:19:39ZEcoinformatics Redmine
Redmine 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 #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 #2437 (Resolved): Cleaner install for spatial componentshttps://projects.ecoinformatics.org/ecoinfo/issues/24372006-05-16T16:46:47ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>Make geoserver install possible from metacat build file and easier integration into the skins.</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 #2186 (Resolved): Customizable web map clienthttps://projects.ecoinformatics.org/ecoinfo/issues/21862005-09-06T17:05:38ZJohn Harrisharris@nceas.ucsb.edu
<p>Currently, the spatial elements displayed within the Metacat spatial viewer are<br />lacking the standard information needed for geographic presentations. The<br />information below should be available for display within the Metacat spatial viewer:</p>
<p>Title<br />Legend<br />Scale<br />Contour Intervals<br />Source</p>
<p>... and there are probably others.</p> Bug #2184 (Resolved): Integrate into skins systemhttps://projects.ecoinformatics.org/ecoinfo/issues/21842005-09-06T16:55:49ZJohn Harrisharris@nceas.ucsb.edu
<p>The Metacat spatial option(s) should be easily included in any skin, so that<br />individuals and organizations may easily customize their sites.</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> Bug #2182 (Resolved): Identifying point goes direct to metadata displayhttps://projects.ecoinformatics.org/ecoinfo/issues/21822005-09-06T16:44:57ZJohn Harrisharris@nceas.ucsb.edu
<p>The user should be able to click on a point (and maybe a polygon) with in the<br />map viewer and have the metdata be displayed for that selected element.</p> Bug #2181 (Resolved): Footprint based queryhttps://projects.ecoinformatics.org/ecoinfo/issues/21812005-09-06T16:43:32ZJohn Harrisharris@nceas.ucsb.edu
<p>Currently, there is no way to submit a query based on a selected region of a<br />map. We need to be able to draw a box (rubberband) as a query that should<br />return metacat result page.</p> Bug #2179 (Resolved): Fix harvesting script to get all points and boxeshttps://projects.ecoinformatics.org/ecoinfo/issues/21792005-09-06T16:25:53ZJohn Harrisharris@nceas.ucsb.edu
<p>Currently, the code that extracts spatial information from EML documents stored<br />in Metacat only grabs points and does not create polygons that better represent<br />the bounding boxes expressed in EML. Also, the code grabs the first of the<br />geographicCoverage sections, instead it should grab all.</p> Bug #2178 (Resolved): Evaluate java-based web mapping applinactionshttps://projects.ecoinformatics.org/ecoinfo/issues/21782005-09-06T15:55:15ZJohn Harrisharris@nceas.ucsb.edu
<p>Currently, Metacat works with MapServer <a class="external" href="http://mapserver.gis.umn.edu/">http://mapserver.gis.umn.edu/</a>, an<br />application that is used to display spatial elements stored in Metacat. To ease<br />the incorporation of a map server into Metacat, we should evaluate the map<br />servers that are implemented as java servlets. Requirements for these<br />mapservers are that they can read/write ESRI shapefiles and read raster data.</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>