On one hand, this project is relatively low risk - we are dealing with technology (OpenLayers, a PostgreSQL/PostGIS database, Javascript, PHP, HTML) that we have already used extensively as a team, and working from a starting point of a previous project (Community Maps).
However, experience shows that the technology aspects of this project should set a few small alarm bells ringing - they are all open source, and this is risky in terms of available support and problem solving. Equally, we run the risk (as does any technology related development or teaching) of potential changes in versions requiring upgrades to our code (the upgrade of our Community Maps project due to a changing Google Maps API highlighted how extensive some of these version changes could be).
How to mitigate this risk - well, the relatively short time-span for this project (Feb - October 2011) allows us to select a version of each platform and stick to it. Beyond that, as we will be making extensive use of the tools in our own teaching, we will upgrade as and when required - documenting our code as we go along will help to facilitate this, as will opening the code up as a resource to the GIS community.
And other risks? We could discover, having talked to our user community, that GIS really isn't for them (or they're just not happy to engage in the project). We hope that this is unlikely - our users are members of interdisciplinary project teams which plan to make use of GIS - but we have identified fall-back scenarios in health epidemiology and coastal environment monitoring, just in case.
www.iiglu.co.uk | IIGLU: Interactive, Integrated, Geospatial Learning and Understanding....... Building a framework for new learners who want to make a map but don't know how
No comments:
Post a Comment