-
Notifications
You must be signed in to change notification settings - Fork 149
Version 1.1
The list below includes enhancements and bug fixes in version 1.1.
At version 1.1 the Geoportal Server has a new and improved metadata editor that includes the following:
- Supports multiplicity, the ability to repeat metadata elements.
- Tabbed based editor that makes navigating the metadata elements easier.
- New display for validation notifications, which includes hyperlinks to the actual required element and instant status message updating when the field has been populated.
- Supports the metadata editor from older versions of the Geoportal.
- Nested Hierarchy
- Integration with 3rd party components such as GEMET (required for INSPIRE).
In Geoportal Server version 1.0, xsd schema validation for metadata profiles is not invoked even when schemas are referenced in the definition.xml files (found in the \\geoportal\WEB-INF\classes\gpt\metadata subdirectories of the geoportal web application). The resulting behavior is that only the definition.xml file rules are used for validation, and xsd schema validation is not invoked. This fix addresses the issue by enabling the xsd schema validation to be invoked if an xsd is referenced in the definition.xml files. Out of the box, an xsd is referenced in the following definition.xml files, although an xsd reference can be added to any of the definition.xml files in the geoportal web application: iso-19115-definition.xml, inspire-iso-19119-definition.xml, nap-iso-19115-definition.xml, and nap-iso-19119-definition.xml.
Fixes defect ID #3158338 (see https://sourceforge.net/tracker/?func=detail&aid=3158338&group_id=306452&atid=1291151)
The synchronizer for OAI correctly retrieves records from an OAI source, but returns the actual metadata content wrapped in an extra <metadata></metadata> wrapper. The result is that the metadata synchronized from the OAI source fails validation and does not publish to the geoportal.
- Apache Tomcat 6.0.13 and earlier not supported. If used, then when users access certain pages (Register Network Resource, the Search page), they'll be redirected to the Home Page. Logfile will show an error that the EL expression cannot be parsed. This is an issue with Apache Tomcat and not Geoportal code. Workaround is to use later version of Tomcat; recommended is version 6.0.24 and higher (but not Tomcat 7.x).
- Geoportal does not support registering new users through Register page or changing a password through the My Profile page if configured with Active Directory.
- When the <metadataaccesspolicy></metadataaccesspolicy> type is set to restricted or public-protected in the gpt.xml, authorized users may get an HTTP 401 error when accessing the resource's Details and Metadata pages. To fix, apply the Restricted Metadata HTTP 401 Patch.
- When the thumbnail in metadata is not found, an empty image displays in the search result/details page.
- Thumbnails with partially encoded URL reference (e.g., http://www.testserver.com/images/Note%20the%20encoding%20here/but no encoding here.JPG), the h:graphicImage java server faces component renders the link with plus signs in the spaces. Workaround is to use fully encoded URLs in thumbnail links.
- Searching ArcGIS.com through federated search allows users to choose Live Data and extent for a search criteria, but these are not supported by ArcGIS.com.
- KML and KMZ file having html code in CDATA section as a description does not get rendered properly and show html string.
- When a document title is long with no spaces, HTML rendering does not wrap the title in search results.
- When OntologyService.war is deployed in weblogic without unzipping the .war file, the Ontology service does not return related terms.
- If a bounding box is a point, foot print on a search map for the metadata is not correct and shows a random bounding box.
- Geoportal calendar does not work properly if a server is set with different locale in JVM such as Buddhist calendar.
- When metadata status gets updated with the checkbox "Apply action to the entire result set", the status change gets updated in search and lucene index files when the next synchronization (to sync between lucene index and database) process runs and finishes.
- For CSW protocol, incremental Synchronization will not reharvest metadata that have been deleted from admin interface.
- If a repository doesn't support last updated date info, Incremental sync will act like full sync.