-
Notifications
You must be signed in to change notification settings - Fork 4
Islandora GIS Solution Pack
The Islandora GIS Solution Pack was developed locally at the Lafayette College Libraries for two projects within the digital humanities for which features necessitating geospatial visualization functionality were scoped. Currently under active development, it offers two separate Drupal Modules:
- islandora_gis
- islandora_gis_geoserver
As specified within design specifications released to the Islandora community, the Content Models structured for the management of geospatial data sets within the Islandora ecosystem are contained within this Module. Currently, only the "simple" Content Model (i. e. the CM implemented for managing compressed Esri Shapefiles) has been used extensively within the staging environment for project development within the Lafayette College Libraries.
Currently, the following tools are leveraged in order to derive geospatial data sets within formats alternative to Esri Shapefiles upon the ingestion of Objects:
- ogrtools
- topojson
These provide one with a command-line interface through which one can generate GML and KML Documents, along with GeoJSON Objects, using any given Shapefile (typically compressed as a zip archive).
While the current release of OpenLayers integrated by the Drupal community does not provide any support for the parsing of TopoJSON Objects, the topojson package offered by the Node.js Package Manager (npm) provides for one the ability to derive from Shapefiles GeoJSON Objects with more granular control over the quality of the GeoJSON Object being generated (in our case, it was necessary to simply and quantize geospatial vector data sets using certain parameters; if this were overlooked, the data served from Datastreams into the OpenLayers JavaScript library introduced significant performance issues for the client's browser).
Ideally, once OpenLayers 3 has been successfully integrated into the Drupal Modules exposing the OpenLayers functionality to the Drupal API's, generating only TopoJSON Objects should deprecate any legacy support for GeoJSON Objects (as they are much smaller in size).
Much praise and gratitude is warranted for the contributors within the GeoHydra project, as this has yielded for a XSL Stylesheet which can transform FGDC metadata Documents (compliant with the ISO 19139 standard) into MODS Documents. Paired with field definitions also provided by the Solr schema Document provided by the GeoHydra project, these resources are ideal for providing a solution for geospatial discovery for Islandora Objects.
The Drupal OpenLayers Module provides for one the essential functionality (and, to a more limited extent, hooks) needed in order to serve Datastream content directly to the OpenLayers JavaScript API as either a base map or a layer. Unfortunately, not many of the options have been abstracted and structured for integration with any Drupal administrative menus. This would likely present a number of feature or improvement requests for the existing islandora_gis Module code base.
More complex issues arise given that at least one use case involving the need to pass symbolization logic (implemented using closures within JavaScript) to the OpenLayers API which, obviously, could be captured and structured using Drupal administrative menus. As such, a larger exchange with the Drupal community maintaining the openlayers Module will likely need to be undertaken in order provide some means through which to provide the necessary closures for symbolizing geospatial features.
While the core Modules developed by the Cartaro project (most significantly, the Drupal GeoServer Module) are integrated in order to interface with the GeoServer web service for the drafting and publishing of web Content Nodes as geospatial features, the GeoServer RESTful consumer is used in favor of straightforward cURL requests in order to transmit Datastream content to the RESTful endpoint for the management, access, and discovery of Esri Shapefiles as vector data sets and GeoTIFF's (i. e. georeferenced images in the TIFF managed within Islandora Large Image Objects) using the GeoServer WMS and WFS features.
From within the RELS-EXT Datastream, a RDF triple using the fedora-rels-ext:hasDependent predicate specifies the URL of a given web coverage as an object for any given Islandora Shapefile Object. As such, Islandora Shapefiles can, then, specify one or many raster layers for the OpenLayers visualization interface (which is used to render either the KML or GeoJSON datastream).
Certainly a less generic predicate is preferable to fedora-rels-ext:hasDependent. It would be ideal to open this discussion to the larger community.
Currently, the bounding box for the maximum extent of any given coverage or feature is structured within the value stored within a dc:coverage element. This is currently structured using a format similar to the DCMI point specification:
xmin=[XMIN]; ymin=[YMIN]; xmax=[XMAX]; ymax=[YMAX];
As feature ID's can be resolved from within the vector data set within the GeoServer (but, not directly within the Datastream itself), these can be resolved to unique URL's. These unique URL's (which, it should be noted, are not necessarily persistent), are structured as values for the dc:relation element:
[GEOSERVER_HOST]/[GEOSERVER_WORKSPACE]/wfs?request=GetFeature&featureID=[ISLANDORA_OBJECT_PID].[FEATURE_ID]
This provides one with the ability to provide event handling functionality specifically for elements within vector data sets for OpenLayers (e. g. for one of the two Lafayette College Libraries projects, the end-user can select individual features which, in turn, resolve to an Islandora Object and render a thumbnail and select Dublin Core elements).
Additionally, this also ensures that requests are directed to the GeoServer WFS and WMS endpoints rather than Fedora Commons directly.