OSSTIP/WP3: Difference between revisions

WP Essentials

This is a Work Package as part of the OSSTIP project.

Inputs:

• Open source geospatial software (both server-oriented and interactive),
• sample datasets and formats from OSSTIP/WP1,
• report of required software dependencies from OSSTIP/WP2.

Outputs:

• Saved install files for chosen tools,
• documentation for setup,
• (possibly) a Linux Virtual Machine (VM) with necessary tools pre-installed.

Estimated Time: Small-medium

Status:

Requirements Summary

The goal of this work package is to design and document how to set up a method for effectively storing and working with the GIS spatial data involved in the project. This is known as a Spatial Data Infrastructure (SDI).

In the case of this project, we’d want the simplest possible system that still provides necessary good management of the data for a ~6 month project involving transport network data analysis. Emphasis should be given to a system that’s feasible to maintain with as little specialist System Administration skills as possible – at least after initial setup. However, supporting robustness and good practices of data maintenance (such as storing Metadata) also need to be considered.

The three key components of the system would be:

• A preferred tool to interactively edit and view GIS data on local PCs. For example, Quantum GIS (QGIS) or GRASS.
• An approach, and/or software infrastructure, for storing key GIS data so that multiple people can use and modify it during the project – along with necessary Metadata. This could be as simple as a common storage area for shapefiles (e.g. on Dropbox) and convention for storing updated versions – through to a specialised GIS server application (such as GeoServer) that incorporates this functionality and provides Web Services access to the data.
• A method or platform for displaying transport network GIS data on the web, as part of indicator platforms or other analysis. Again, simpler approaches for this might be converting the data to KMZ format for display in Google Earth, whereas a software approach to automate this could be to use GeoServer and integrated software such as OpenLayers to display the data.

An important factor in determining the best system should be integration with the GIS-T software evaluated in OSSTIP/WP3 in mind. For example, OpenTripPlanner is developed by the same organisation that supported GeoServer’s early development, so is likely to integrate well with this platform.

Added notes:

• An Australian project to support the rollout of such a system on a larger scale is the AuScope SISS project - http://siss.auscope.org/

Results

(TODO)