Vesuvius Google Summer of Code 2014 - Pre-Award Archive

Vesuvius will once again be mentoring projects for GSoC. For newbies to the project:

• Introduction to Vesuvius
• Installation instructions
• Sahana Mailing Lists

Mentors will see more about each student and proposal in their Melange application. Row order is by idea category (as listed in “Ideas” section); the order within a particular idea category is random. Some proposals may encompass aspects beyond those given in “Ideas”.

This is included here for completeness. Idea categories are in the order listed as Eden bigger coding projects. [TO DO: Do the proposals marked as “?” address existing ideas for coding projects, or are they new? In either case, replace “?”]

These do not reference Eden or Vesuvius and may be entirely unrelated to existing platforms.

Knowledge required: PHP, Javascript, Mongo DB

Often due to the rapid response requirements of disasters systems fail when they cannot be flexible. The typical fixed forms based approach for capturing disaster input can be constrictive when we could do with one more field in the form to capture some essential data and analytics. Mongo DB is a noSQL document based store that can help facilitate such a requirement. Would like to experiment on an alternative branch that helps explore who we can integrate Mongo Db replacing MySQL in Sahana Agasti.

The following needs to be developed:

• MySQL replacement by MongoDB in Sahana Agasti
• Integration of MongoDB to through an ORM layer like Doctrine
• Creation of the dynamic forms mechanism in the framework
• Creation of base forms for 1-2 Modules
• Analytics on the MongoDB data (optional)
• Integration of MongoDB into the portable app (optional)

Mentors : Chamindra De Silva, Ramindu Deshapriya
For More : MongoDB Integration to Vesuvius

Knowledge required: PHP, Javascript

Agasti presently does not have a Object Relationship Mapping Layer such as Doctrine. It would be beneficial to have such a layer particularly to be able to support multiple database types to enable Agasti to be more flexible. It also lends itself to better design and maintains of data objects in the system.

The following needs to be developed:

• Integration of an existing ORM such as Doctrine that has support for MySQL, Oracle and MongoDB
• Pre-configuration of the ORM for MySQL
• API documentation and sample code on the WIKI

Mentors : Chamindra De Silva, Ramindu Deshapriya
For More : ORM Layer for Vesuvius

Knowledge required: PHP, Javascript, XML, JQuery

The current Sahana Vesuvius Installer is in its very rudimentary stages. This needs to be completed as a working, fully-fledged, module of Vesuvius. The following needs to be determined/developed:

• The extra steps needed in the installer
• Error message management
• Wrapping up installation process
• Fixes for current issues

Mentors : Ramindu Deshapriya
For More : Vesuvius Installer Completion

Knowledge required: Android, Apache

Modern smart devices are capable of running an Apache web server instance without any problems. With the additional functionality of being able to host a wireless network, this give the ability to use mobile devices as portable web servers. This is extremely useful in the context of disaster response and management.

We would like to initially build an Android app which deploys an Apache + MySQL stack on top of an Android device and runs Vesuvius on top of it.

The following high-level steps have been identified:

• Research into deploying Apache + MySQL on top of Android
• Research in to running PHP + MySQL on top of Apache deployed on Android
• Development based on research
• Running Vesuvius with mod_rewrite and other configuration options enabled on top of an Android device
• Hosting a publicly-accessible Vesuvius server instance which can be accessed via wireless

Mentors : Akila Perera, Ramindu Deshapriya
For More : Running Vesuvius on Portable Devices

Knowledge required: PHP, MySQL, JQuery/Javascript

Sahana Kilauea is a product used in conjunction with Sahana Mayon by the City of New York. However, as this is merely a flavor of Vesuvius, we need to merge in the modules from Kilauea in to Vesuvius to create a single complete product. The initial work for this was accomplished during GSoC 2013, however, we need it to be completed and polished off this year. The action items associated with this project are:

• Analysis of Kilauea and the Vesuvius/Kilauea merge branch to derive what is missing from the merge branch
• Identify discrepancies that could occur in the database due to the merge
• Bring in any missing functionality from Kilauea to the merge branch
• Developer testing for the merged modules

GSoC 2013 Project :Vesuvius/Kilauea Merge

Mentors : Yasitha Pandithawatta, Ramindu Deshapriya
For More : Completion of Vesuvius-Kilauea Merge

Knowledge required: SOAP, PHP

Native Sync aims to synchronize data between different instances of Vesuvius. This was completed to a great extent during GSoC 2013. This year, we would like Native Sync to effectively integrate with the Dynamic Portable App module of Vesuvius to push and synchronize data between portable apps.

Native Sync GSoC 2013 Project: Native Synchronization between Vesuvius Instances

Mentors : Greg Miernicki, Gurutharshan Nadarajah
For More : Completion of Native Sync

Knowledge required: Javascript, web design. Helpful: SUDS javascript library for SOAP calls, PHP

During disaster events, data is managed in many different formats. Spreadsheets are predominantly used to store data in these situations. This project aims to create an import wizard for Vesuvius that will be able to import missing-person structured data from such sources.

The Vesuvius “PFIF” module permits bulk exchange of records about persons lost and found, e.g., with Google Person Finder. However, sometimes bulk person data comes in other forms, for instance, as an Excel spreadsheet in the case of the Joplin, Missouri tornadoes. We would like to provide a GUI wizard, like that used in Microsoft Office products to flexibly import tabular data for record creation, but be easier for non-programmers to use than, say, XSLT. The wizard would allow import from common file formats (tab-separated text, comma-separated text, Excel, etc.). It would allow mapping of input columns to crucial Vesuvius input fields. This mapping includes column skipping, flexible ordering, and missing-data fill-ins.

If time allows, other transformations are desirable: within-column (e.g., case adjustments, enumeration mapping) and cross-column (e.g., string merging and splitting).

March 9 Update: the architecture for this wizard has been reconsidered, as described here

It draws on javascript and client web-service skills, and far less on PHP/SQL skills as originally conceived. There are some scope simplifications as well. The foregoing doc does not address the UI design, and making sure its flexible and responsive. It is suggested that the import wizards available in spreadsheet programs (e.g., traditional MS Excel) may provide inspirations.

Mentors : Greg Miernicki (Javascript/HTML/CSS, SUDS, web service calls, PHP), Glenn Pearson (domain, UI design, web service calls)
For More : Import Wizard for Missing and Found Persons

Knowledge required: PHP, MySQL, Web Services. Helpful: Familiarity with NuSOAP, Solr search engine

Organizations often have great reluctance to share data, for many reasons. This is as true in the missing-person arena as elsewhere. The Missing Person Community of Interest, of which Sahana is a member, has sought to address this. One approach is to allow cross-organizational search, with minimal interchange of data, through web services. A specific design for this was was first put forward here by one of the mentors. A portion of this design has recently seen particular interest; Google and RefugeesUnited have expressed interest in developing and deploying implementations.

This project would add these capabilities to Vesuvius. There are two aspects:

• Services that receive search requests from outside organizations, validate the request, perform the search, and package and return the results.
• A user-interface extension that allows search-term formulation, selection of target organization(s), initiation as a web service client of the search request, and reception and display of the resulting data links. (Google's proposed approach to this is as an embeddable widget; this is not necessarily how Vesuvius might approach it.)

In terms of priorities during GSoC:

• For the services that receive search requests, the 2 services in Tim's doc (the second link above) should be implemented. Secondary would be:
  • a caller-authentication scheme such as OAuth (which some organizations may desire and others not);
  • additional alternative web services described in the first doc.

• The user-interface extension that supports the foregoing. This interface could be either separate from the existing Vesuvius search, or integrated into that search… the proposal should develop a design for one or the other. Of secondary importance, would be to have the design allow for:
  • the possibility that there may be multiple external organizations to search;
  • that different organizations will likely have different names for the same disaster event.

Suggested milestones:

• Demonstrate this functionality with a single Vesuvius instance that calls its own web service.
• Replicate this results with two Vesuvius instances on separate machines.

Mentors : Greg Miernicki, Glenn Pearson
For More : Federated Search

Knowledge required: PHP, MySQL, Javascript, AJAX

An instance of Vesuvius is being built for the Disaster Management Unit at the Ministry of Health, Sri Lanka. This particular customization focuses heavily on the medical aspects of emergency response, with a distributed network of medical Focal Points maintained as the key action centers around the country. A set of new modules are being added/existing modules being customized to fit the requirements provided by liaisons at the Postgraduate Institute of Medicine (PGIM) Sri Lanka.

GIS is a vital tool in disaster management and there are many uses of it. Parallel to the latest modifications and developments in Vesuvius, a new GIS module is planned. After completion, the GIS module should be able support the Disaster Managers/Decision Makers by providing valuable information throughout the disaster management cycle (I.e: Pre-disaster and Post disaster). Initially the GIS module will be developed targeting one selected district. The GIS module should have the following;

• Demarcations of GN areas within the district
• Population data
• Water resources (lakes, rivers, main distribution centers)
• Forests, bare land, etc
• Elevations
• Important public offices (police, army camps, GN offices, AGA offices, DS offices, etc)
• Hospitals
• Roads
• Religious places
• Pre identified safe areas for temporary shelters, in floods, tsunamis, etc

GIS module will be developed as a separate module and will be integrated with ‘Sahana-DMU’ at deployment. Therefore, a basic idea about the modules in ‘Sahana-DMU’ is necessary. User requirements of the GIS module will vary depending on the phase of the disaster management cycle (Pre-disaster and Post disaster). Some of the common requirements that must be fulfilled include;

• Pre-disaster
  • Visualize data in different layers, highlight high risk centers (points),
• Post-disaster
  • Add disaster data to respective layers (Data gathered through RAT module), Ability to demonstrate selected indicators. e.g. Distance to the nearest hospital from the disaster area, population affected, etc

• Disaster Management Information System
• Project Proposal
• Supporting Modules

Mentors : Roshan Hewapathirana, Prasanna Weerakoon (PGIM), Akila Perera, Ramindu Deshapriya
For More : GIS Module for Sahana - DMU Sri Lanka

It is expected that all students follow this template for their application. Entire Application should be within 7500 Characters.

• Name
• Communication details - Email*, Freenode IRC Nickname*, IM, Skype, Blog etc (* compulsory)
• Include Biographical information about yourself, your education, country, timezone etc.
• If you have a link to a resume/CV/LinkedIn profile, include it here
• Please provide an overview of your exposure to similar technologies and/or FOSS in general.
• Please answer the question - “Why would you like to help the Sahana project?”

• Have you reviewed the timeline for GSOC2014?
• Do you have any significant conflicts with the listed schedule? If so, please list them here.
• Will you need to finish your project prior to the end of the GSOC?
• Are there any significant periods during the summer that you will not be available?

Provide a brief overview of the proposed idea and objectives you want to achieve with it here. (250 word limit).

This section is to provide the detail of your project proposal. Take as much space as is necessary.

• Project Deliverable - What is the essence of the project? What capability are you looking at adding to Sahana that will expand its capability for emergency/disaster management?
• Project Justification - What is the relevance of your idea to the project? Why do you think its important to *have* this idea integrated to the Sahana system.
• Implementation Plan - How are you going to implement your project? Use this section to expand in as much detail as possible how it should be constructed.
• Future Options - Identify some aspects of the project that may not be within the scope of this submission, but could form the basis for future work that would build upon the outcomes of your project
• Relevant Experience - Please list all experience you have that is directly relevant to the proposed project, and how they would help you deliver the project. If you have contributed to the Sahana project previously, please clearly outline your contributions.

You can also include links to additional details like diagrams etc outlining your ideas acting as supplementary information for your proposal outside of this scope. But it is highly advised to follow the KISS principle and stay as specific as possible.

Clearly outline your timeline and goals for the project. All goals must follow the SMART (http://en.wikipedia.org/wiki/SMART_%28project_management%29) methodology - they should be Specific, Measurable, Achievable, Realistic and Time-bound. Each goal should explicitly tell us how we can measure it (e.g. code committed to trunk and can be assessed on a demo site) and the date it is due. This should be provided as three columns - Due Date, SMART Goal, and Measure. The project is looking for explicit and well-written goals - proposals that contain broad and general goals will not be accepted. The more specific your goals, the better chance you have of being accepted.

These should be broken down into the following stages.

1. Work already undertaken - What research have you undertaken in this area in advance? (these can just be bullet points and are not required to follow the SMART methodology)
2. First trimester (21 April - 19 May) - identify the SMART goals you have for the community bonding period. Most of these are likely to revolve around further scoping of the project with the community, engaging with the community, and updating and finalizing the project plan.
3. Second trimester (19 May - 27 June) - identify the draft SMART goals you have for the first half of the project. These will be used to assess project process and form the basis for the mid-term evaluation.
4. Third trimester (27 June - 18 August) - identify the draft SMART goals you have for the second half of the project. These will be used to assess the whole project and in conjunction with the mid-term goals, form the basis for the final evaluation.

We recognize that the goals may change during the project, and the mentors will accept modifications to the goals at any time. For example, discussion during the community engagement stage may change the scope of the project, and the goals may need to be subsequently modified. As such, the goals are not hard-and-fast, but we do want to see reasonable effort go into the initial project timeline.

The Project Goals and Timeline will form a significant part of the assessment of your application, as well as mid-term and final evaluations.