Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362006-12-12T19:59:47ZEcoinformatics Redmine
Redmine Bug #2695 (Resolved): Loading map message persists when a WMS is downhttps://projects.ecoinformatics.org/ecoinfo/issues/26952006-12-12T19:59:47ZMatthew Perryperry@nceas.ucsb.edu
<p>When an external WMS server goes down, mapbuilder will continue trying to load the layer.. or at least will continue showing a message stating "Loading 1 map layer". If the server is down, the message never goes away and this is very distracting.</p>
<p>Ideally we could implement a timeout whereby mapbuilder would remove the message after a reasonable amount of time (20 seconds) if it had not recieved a response yet. Also a notification such as "Layer X could not be loaded" would be helpful.</p>
<p>I spoke with the Mapbuilder team about this and no one has implemented a solution but they'd be interested in including a patch in the next release assuming we can develop a fix.</p>
<p>The relevant source file will likely be metacat/lib/spatial/mapbuilder/lib/widget/MapPane.js</p> Bug #2692 (Resolved): Use .jsp and reduce token usage in skinshttps://projects.ecoinformatics.org/ecoinfo/issues/26922006-12-07T00:38:40ZMatthew Perryperry@nceas.ucsb.edu
<p>The following skins (esa, nrs, obfs, nceas) should be updated to use .jsp and replace use of tokens as much as possible. If runSpatialOption is false, don't display the map.</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 #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 #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 #2190 (Resolved): Metacat Spatial Option Admin Pagehttps://projects.ecoinformatics.org/ecoinfo/issues/21902005-09-06T17:17:11ZJohn Harrisharris@nceas.ucsb.edu
<p>The Metacat Spatial Option needs an admin page so that the Metcat administrator<br />can administer the configuration of the spatial options. The admin page should<br />include:</p>
<p>upload GIS elements (georef'd images, shapefiles etc..)<br />set which elements should be available to end-user<br />set projections<br />set the geographic presentation info to be displayed (scale bars, titles etc..)</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 #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>