Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362006-09-11T22:26:26ZEcoinformatics Redmine
Redmine Bug #2553 (New): squery needs to handle spatial queryhttps://projects.ecoinformatics.org/ecoinfo/issues/25532006-09-11T22:26:26ZMatthew Perryperry@nceas.ucsb.edu
<p>The current metacat spatial query is based on simple comparison of the four bounding values which is slow and potentially inaccurate. see ( bug 2552 )</p>
<p>The squuery code should be able to recognize when a spatial query is being performed and pass that off to the SpatialQuery class ( again bug 2552 ). Might want to review DocumentIdQuery for code to convert the vector of docids into a valid squery.</p>
<p>Ideally, we could update the squery dtd to include special tags for spatial queries, possibly following the OGC Filter specification.</p> Bug #2548 (New): Architecture for filtering features from WMS requestshttps://projects.ecoinformatics.org/ecoinfo/issues/25482006-09-11T22:00:04ZMatthew Perryperry@nceas.ucsb.edu
<p>Currently, all of the documents in the metacat database are stored in the spatial cache. When the web client requests a map image, all the features in that extent are shown.</p>
<p>We need to intercept the WMS request (possibly by using a servlet filter, possibly by writing our own WMS handler) and prevent features from being included in the map based on various contraints:</p>
<p>1) Access permissions. If a user doesn't have read permissions, they shouldn't see the feature in the map.</p>
<p>2) Queries. The WMS request may be paired with a non-spatial query, the results of which should define a subset of documents that are to be drawn.</p>
<p>3) Skin configuration. Some skins may want to filter the map features based on organization name or other contraints.</p>
<p>For now the critical part is the access constraints. In the mean time, we'll just cache only public docs.</p>