Geographical Information Systems for Sahana

Interested Parties in Sahana GIS

  • Mifan Careem (GMT +5.30)
    • Mifan is part of the Sahana core team and PMC, and leads the GIS development effort on behalf of the Sahana core team.
  • Fran Boon
    • Fran is a Sahana developer focussing on GIS. He is also a member of the PMC. His day job consists of coordinating IT support across Oxfam GB's 150 field offices.
  • David Bitner (GMT -5)
    • David works as the GIS Coordinator for an international airport and as an independent consultant focusing on open source GIS software. Being active in the OSGeo community, David hopes to act as a liaison between Sahana and OSGeo and to help create an extensible GIS architecture for Sahana.
  • Gavin Treadgold
  • Nate Olson
    • Nate is prepping a Web-based project that aims to highlight the many overlapping pieces–the “big picture”–of humanitarian projects in a complex, interdependent world.
  • Mikel Maron
    • Mikel is a web developer focused on mapping, things like GeoRSS standardization and OpenStreetMap, interested in applying the lightweight web mapping approach (neogeography) to disaster response.
  • Brent Wood
  • Wendy Edwards
  • Hasitha Anjana
  • Richard Smith
  • (Add your name)

Abstract

This document outlines the requirements for GIS/mapping functionality in Sahana. The draft is a proposal based on ideas of the authors, and is not an agreed plan at this stage. It includes excerpts from an earlier document written by Mifan Careem, which is available here. This document does not attempt to define how Sahana will store or manage spatial data, but we hope it will provide a framework by which such data are made available in map form to users

Goal

To provide generic mapping functionality from Sahana utilising industry standards to maximise interoperability with existing FOSS/GIS applications

Meetings

Regular conversations happen on #Sahana on Freenode.

Please include GIS in the subject of any emails to the Sahana Mailing List.

Features of the Current GIS Library

  • Plugin architecture similar to the Sahana framework which automatically detects and handles GIS plugins
    • OpenLayers plugin
    • GoogleMaps plugin (deprecated in 0.7. Google data accessible via OL)
  • API for Sahana modules to access the functionality regardless of the backend implementation.
    • Ability to add location co-ordinates to module features, with a map window option for placement
      • e.g: add camp
    • Ability to view module features on Map
      • e.g: view all camps
    • Ability to thematically map module features
      • e.g: display camps coloured according to population size
  • Situation Awareness module
    • Add Landmark features
    • Add Situation features
    • Display features from any module together
    • Do basic geospatial analysis operations (e.g. radius)
  • lib_validate.inc functions to sanity-check coordinates entered

Features of the New GIS module(s)

We are implementing these new modules:

  • Map Viewing Client*
  • Map Service Catalogue*
  • GeoRSS Export*
  • GeoRSS Import*
  • Map Editor
  • Cascading Map Server
  • Spatial Database
  • GIS Analysis
  • GeoSearch*
  • CSW Client*

(* indicates that these modules should not contain any additional server side software requirements)

The GIS client and server modules should run independently, so the servers can operate on the same or different hardware as the client, and a single server could support multiple clients. No LAN or internet capability should be required for full functionality, but if either are available the system should be able to make use of them.

These modules should support and take advantage of OGC standards (WMS, GeoRSS, KML, Catalogue Services) wherever possible. For papers defining these standards, see: http://www.opengeospatial.org/standards/cat. Note, however, that the standards-based approach suggested here for modules to serve, access and display geographic data also facilitates the development of a Sahana module providing an interaction with the data within map layers, as well as with the layers themselves, largely independent of the formats used to manage the data. (Provided such data is not stored in non-standard formats).

Architecture Diagram

Proposed timeline

  • 0.6.x stable uses GoogleMaps as-is
  • 0.7.x stable uses OpenLayers (accessing different back end baseLayers) & has a Catalogue module.
  • 0.8.x stable has an integrated WMS/WFS server (with PostGIS included) & uses GeoRSS for markers & extends the Catalogue module to WFS
  • 0.9.x stable has a dynamic OWS explorer (possibly based on MapBuilder)

ToDo list

Map Viewing Client

This module allows for mapping of resources utilizing GeoRSS and WMS services as well as commercial API's such as Google Maps, Microsoft Virtual Earth, and Yahoo Maps.

This is currently implemented using OpenLayers.

NB From the WMS spec, “developers of user interfaces for WMSs are cautioned that all references to latitude and longitude, for example user input of bounding box or readout of cursor coordinates, should show latitude before longitude.”

Whilst the Map Viewing client is accessible to other modules (for adding the coordinates of a new object & for Reports), the main usage is envisaged to be by the Situation Awareness module.

Potential Existing Projects

Map Service Catalogue

This is a PHP front-end for managing access to locval & remote geospatial data feeds: adding/deleting, enabling/disabling.

Could usefully have an extra page which lists a few sites which collate these services (prior to the full OWS explorer).

Fields required for each service type in the catalogue

The information stored in the database using this field information should be enough to describe each service and to dynamically write the setup for that layer within OpenLayers (Possible layer types and required information can be found at http://dev.openlayers.org/docs/files/OpenLayers-js.html by looking at the documentation under “layer”).

Overall listing
  • Name
  • Description
  • Layer Type
  • id
Google Layer
  • api key
Yahoo Layer
  • api key
GeoRSS Layer
  • id
  • base url
  • min scale to display
WMS Layer
  • id
  • base url
  • layers
  • image type
  • whether base layer or overlay
  • min resolution
  • max resolution
  • profile for tiled service if available (ie for WMS-C coming from TileCache)

Map Editor

This module allows Sahana users/administrators to:

This was initially developed during GSoC 2008

This module will allow Sahana users/administrators to:

  • create new layers/datasets (from scratch) and populate them if appropriate
  • add/delete/modify new records/features to existing layers/datasets (spatial & aspatial fields/values)
  • provide easy access to these services via the Map Service Catalogue
  • manage access constraints to the datasets
  • reproject non-lat long datasets to lat/long for GeoRSS & general Sahana use

A future enhancement could be to provide access to Sahana data via WMS (an image can be a lower volume of data than the raw data & some clients don't support GeoRSS or KML). If we still stores data in MySQL as simple Lat/Lons then this approach would have been suitable: http://mapserver.gis.umn.edu/docs/howto/ogrmysql

Potential Existing Projects

(* back end/middleware libraries for acessing or manipulating spatial data)

GeoRSS Export

This should allow for the provision of internal Sahana spatial data as a GeoRSS feed.

This module can use the existing XML export mechanism as a model. A feed will need to be a directly callable url. This module could also be modified to include other formats such as Google KML.

Current plan is to use SimplePie for this.

We could potentially use this for internal Markers layers to reduce maintenance:

The GeoRSS is written out from the current database storage format to the web-accessible filesystem & hence is also accessible by remote GeoRSS viewers.

GeoRSS Import

This should allow for Sahana to import data from datasets utilizing RSS feeds that contain GeoRSS tags and possibly other standard namespaces.

Currently GeoRSS feeds can be viewed via the Map Viewing Client, but it would be good to also import these into the main database (like for GPX & KML)

Cascading Map Server

This module should allow for the use of GIS datasets (vector and raster) and data from Sahana to be published as WMS/WFS. This should also be able to cascade other WMS/WFS services. This module will rely on additional software (e.g. MapServer) than what is already required for Sahana.

Potential Existing Projects

  • MapServer - standard for WMS & WFS.
  • GeoServer - Java-based, good for WFS-T
  • Deegree - Java framework offering the main building blocks for Spatial Data Infrastructures
  • TileCache to increase performance

Spatial Database

This will provide full spatial data and aspatial data management capability, including insert, update, validate and query capability. It will provide data to other GIS and non-GIS Sahana modules. Ideally it should comply with ANSI:SQL and OGC:SFS standards. It will allow for simple spatial analyses on the fly within other Sahana modules. Examples include finding all of one resource within some distance from another resource.

Until we add PostGIS to the stack, an intermediate step is to save as WKT in MySQL text fields. Useful thread on using these in OpenLayers.

Potential Existing Projects

GIS Analysis

This module provides geospatial analyical and modelling capability beyond that provided by the functions available in the spatial database module.

Currently implemented:

  • shn_gis_features_in_radius($lat,$lon,$radius)
    • Used for:
      • What Situations have been reported within a x km radius of my location?
    • Could be used for:
      • Water supply must be <500m from Shelter
      • WC must be >50m from Shelter

Potential Existing Projects

  • GRASS - Geographic Resources Analysis Support System
  • PL/R - R procedural language for PostgreSQL
  • R - Statistical Computing environment
  • OpenModeller - niche modelling environment
  • PyWPS - Python implementation of OGC's WPS (Web Processing Service) which accesses GRASS or R/GDAL to process the data
    • Embrio Web UI in PHP/MapScript

Example Ideas:

A number of Desktop GIS tools could also be used as part of the workflow:

GeoSearch

This module will provide geospatial search.

Potential Existing Projects

Cataloguing

This module will allow other systems (such as GeoNetwork) to catalogue the data we hold in our instance:

  • Features (served via GeoRSS or KML)
  • Rasters/Vectors held on the integrated MapServer

Catalog Service for Web Client

CSW Client to search for external feeds from catalog servers and automatically bind to them. Currently I'm implementing this in the Mapbender project - hopefully the same can be re-architectured to be included here. This module will strengthen Sahana integration with WMS and Cat servers and cement its place in the SDI


Navigation
  • Navigate