This is an old revision of the document!


Google Summer of Code 2010 IDEAS

Introduction

This is the ideas list of the Sahana (PHP) project for the Google Summer of Code, 2010.

We have been involved with GSoC in 2006, 2007, 2008 & 2009. These involvements have been very effective in building both the project and the community, so we are looking forward to having another productive year as well…

Below are the tentative ideas of the project, but you are also encouraged to submit new ideas as well….these can be discussed on IRC or the Mailing List.

Student Guidelines

You can also check out the following to know how to get started with Sahana development from scratch.

Project Ideas

Sahana Logistics Ideas

DESCRIPTION

Logistics module is a large module that includes lots of functionality. Building the entire project by one person is not practical. If independent sections of the module can be identified and developed separately it would be a good start for logistics.

For all these sections to work together when combined several guidelines will have to be followed. Adhering to a common database structure by everyone. Using a common API to access the data and functionality.

Logistics module sections

Item Catalogue Idea

Item Catalogue should be able to create the item catalogue for sahana(Logistics).

It will include a categorization of the various items. Each category can have either more sub categories or items. A item can be individual item or a composite item that is made up of multiple items of the same type or different item types.

Red cross item catalogue - http://procurement.ifrc.org/catalogue/

Catelogue Management

Item Catalogue should have a management functionality. CRUD new categories , CRUD sub categories under a parent category, CRUD items. CRUD of sub items under a parent item. ( the sub items too should be included as a record in the Item catalogue)

When adding items, a item that is not already in the catalogue should be added. This should be placed in the system as a temporary item, then a administrator should be notified about the new item catalogue record. If the admin verifies the new record, it will be added to the catalogue. if not added, a alternative record of the catalogue has to be selected.

Controller/widget plugin

Various other sections of logistics will need to access the item catalogue ( eg. add a new item into warehouse , add a item to a shipment ). For the aid catalogue to be accessible through other forms, a item catalogue controller that and be easily added to other forms is required. This controller could be like a jQuery plugin.

This should provide the following - ability to browse through the categories and find a item from catalogue. search for the item name and find items from catalogue. search for item category and find a item.

Logistics Site Functionality Idea

A logistics site can be a intake point ( airport , port , collection center ) , a warehouse , a camp or a shelter. Basically any entity tracked by sahana as a place where items are managed can be considered a site.

Storage Location - A site can have multiple locations where items are stored, these are called storage locations.

Site Management

CRUD of a site should be possible. Associating any sahana location entity ( organization, camp, shelter ) with a logistics site should be possible. CRUD of storage locations to a Site must be possible.

Items in Site

Various items can be stored at storage location of a site. This item could be a single inseparable item or a composite item

All the items stored in a Site should be retrievable , editable, deletable ( should audit what happened , why deleted). All the items in a storage location should be retrievable, editable, deletable and should be transferable to another storage location in the same site.

Item Shipping

A shipment to be sent to a different site has to be created from the items stored in a site. When creating a shipment, items to the shipment can be added by selecting the items in stock in the site. All the selected items are temporarily deducted from the site and placed in a temporary location till the shipment is completed. When the shipment is completed, the items are removed from the site and permanently stored in a location to be loaded in to transportation.

Shipment Receiving

A pre confirmed shipment can be added to a site with the hope of intaking it when the shipment arrives. The shipment details are either received from a different site or added manually from a document. When the shipment is received, each of the items are received into the site together with checks being made to verify if the shipment received is complete. If there are differences in the received shipment, the differences should be recorded ( damaged , lost ).

Logistics Shipment Functionality Idea

Vehicles used for logistics need to be registered in the system. These vehicles can be any type of a vehicle ( trucks, boats, cars, jeeps, helicopter, ship).

A vehicle should belong to a vehicle category. Each Vehicle could be assigned to a site as the vehicle's hub.

When a shipment is being loaded on to a vehicle a shipment is being marked to a state of being “shipped”. The Shipment can have various transit points while its being transported to the final destination. At the final destination, the shipment is intaken to the destination's site.

A vehicle could be shipping either one or multiple shipments in one trip. There can be a functionality to find the route that has to be followed to deliver the shipments. For each trip, a driver/responsible person can be assigned, he would be responsible about the items that are being shipped.

Item Shipping - reuse the above feature under the above idea

Shipment Receiving - reuse the above feature under the above idea

Item Functionality Idea

Item Kitting

Dekitting

Adjusting units of measure

Distribute item to recipient( organization or individual )

Record destroyed items

Record lost items

Record damaged items

NOTE - destroyed , lost , damaged should record all additional information that are required to determine at which point the items were destroyed, lost or damaged.

Reorder levels for items

Request stock low items

Country Customisation

by Gavin Treadgold

There are many aspects of Sahana that need to be customised to suit a specific country before Sahana can be effectively deployed. There is a need for a system that allows experienced Sahana administrators to customise and configure Sahana for a particular country. These setting and database entries then need to be saved and implemented in the administration section of Sahana to enable easy customisation of a Sahana server to suit a particular countries requirements. This may involve the creation of a configuration file that contains all database inserts (e.g. to create regions, set name preferences, forms of ID, preferred units, currency etc).

Additional thoughts by Glenn Pearson

Sahana “Central” might want to create its own large data repository, of pre-formatted, pre-vetted data (but in some cases automatically refreshed from sources), from which the new administrator could pick and choose using a wizard.

For example, for the Location Hierarchy and Country List, there could be a map-based interface to quickly select/prune geographic areas of interest from a “gazetteer” database. (Current, for Location Hierarchy you can define more levels to the hierarchy than you may need, and then hide levels above or/below those of interest when a disaster actually occurs. But there's no way to hide siblings on the fly, e.g., show country A but not country B.)

For more, see our discussion about some of our experiences in configuring and customizing Sahana content for a particular project, including coding standards and data sources.

Additional thoughts by Michale Howden

How about a master list of catalog items? That would be valuable, but very time consuming. Or suppliers? Regarding importing settings, I would say that csv files are a good way to go. They can be edited by a non-technical user.

Sahana Reporting Module

Reporting is one of the essential component in most of the software systems but the SAHANA seems not to be armed with a good reporting mechanism. Although it has two reporting modules named as Reporting and Dynamic reporting, the functionality or the features of those modules are not up to the standard of enterprise level software.Therefore we expect to bring reporting capability of enterprise grade software systems to the SAHANA and hope that would be helpful for most of SAHANA users.

Proposing module should be capable of handling large databases (millions of records ) and should be efficient as well as user friendly. Besides it would be plus point for you if you could provide us information about what are the reports that you can generate and would the module can be extended for future needs.

DESCRIPTION LINK TO WIKI PAGE

SKILLS REQUIRED:

Sahana Module Manager

by Greg Miernicki

Sahana features a framework that allows new sections of the site to be written in the form of modules. Currently, this framework identifies and installs all modules that reside in the /mod folder of the site's installation. This is far from optimal as most instances of Sahana 'in the wild' do not use all of these modules. So, for example, a typical installed instance of Sahana may choose to utilize only 5 of the (currently 40) modules that come with it. The way to do this would be to uninstall/disable modules that are not needed via a Module Manager.

Preliminary work has already been done for this effort in the form of :
- Module Manager interface (not completed) built into the Admin Section of Sahana
- The specification of what constitutes a 'module' in terms of packaging, file contents, and associated metadata files is already underway.
- Aggregation of this information on the wiki will be performed by the Mentor previous to the GSoC student discussing the points, fully spec'ing out what needs to be done and fulfilling on the actual coding implementation

If the above work is completed, additional research/work could go into providing a Sahana Module 'App Store'. The app store would host modules and integrate with the module manager such that searching for new modules, installing new modules, and upgrading existing modules could be performed.

Integration with Usahidhi

by Chamindra de Silva

Ushadihi and Sahana have been working together in disaster response in particular during Haiti. Ushadihi is a great crowd sourcing tool that can obtain and plot geolocated SMS from the field during a disaster. But the SMS can be for various things, from a request for aid, to a report from a relief worker to an identification of a hazard. The SMS can be from victims, relief workers or donors and some work needs to be done to classify the requests. Sahana can provide a lot of value by introducing a process of collective classification and validation of requests and subsequently piping them in the appropriate form for processing in the relevant sub-application. Build an library that process the GeoRSS feeds from Usahidhi and has a mechanism of both auto-tagging and manual tagging, such that the requests then get piped as inputs to be processed in the respective Sahana module (Request Management, Volunteer Management, Organization Registry). In your proposal please provide the interface that would deliver this functionality.

Referential Integrity

by Glenn Pearson

Referential integrity within a database is the defining of foreign key relationships between database tables. This simplifies enforcement of data validity on input or update, and allows better management through, for example, cascade deletes. Not all databases support foreign key relationships. Traditionally, Sahana has relied on business rules expressed in PHP, which has the advantage of portability across databases. But coverage of such rules can be spotty.

It would be helpful to create an experimental instance of Sahana with (for example) MySQL, where foreign keys are defined, and any parts of now-redundant business rules are conditionally disabled.

A New Protocol for Missing Person/Disaster Victim Records

by Glenn Pearson

In response to the Haitian earthquake, Sahana PHP has been developing capabilities to import and export missing person records in PFIF 1.1/1.2 formats, e.g., for interchange with Google and other aggregators and sources.

But this is not the only potential format. The US Department of Homeland Security/Federal Emergency Management Agency (FEMA) is currently creating a primarily-US XML standard for patient tracking (Phase I) and eventually disaster-related people tracking (Phase II). FEMA's effort is attempting to address significant US data-exchange problems, within an US legal and medical framework. The Phase I work, “Tracking of Emergency Patients” (TEP), uses an “EDXL wrapper” for distribution routing; it will be submitted shortly to OASIS as an “EDXL payload” standard. (Our US National Library of Medicine customization of Sahana has made some use of a predecessor EDXL format.)

The Phase II work, originally called “Tracking of Emergency Victims” (TEV), and now “Tracking of Emergency Clients” (TEC), will be of particular interest to Sahana. It will build on TEP, but will presumably be different in some regards. Since it will not be well defined during summer 2010, work in that time frame would focus on feedback to the standards bodies.

For more, the starting point is FEMA's EDXL-TEP Site

Pertinent documents (both overview and technical) are here and its “TEP Project Documents” subdirectory.

Desirable results -

  • At a technical level, a Sahana module that imported/exported/stored TEP records and mapped them to existing Sahana classes/tables would be helpful.
  • At a policy level, suggestions for what TEC should look like to support Sahana and non-US deployments (with potentially different legal/medical frameworks) better would be valuable. Or proposals for alternatives to TEC and PFIF for these uses.

Passive Synchronization of Global Unique IDs Over a RESTful Interface

by Andrew Lee:

If every module has a well-defined, RESTful API, any of them can be distributed.

As an example, the “Camp” or “Food Request Module” can function as a Consumer-Aggregator-Syndicator service that uses a common RESTful API. Each can expose common response methods, internal aggregation methods, and communicate with other modules via a common syndication method that uses a controlled vocabulary. This controlled vocabulary can be defined independent of any particular module and exist, for example, as an XML namespace.

The Sahana Foundation has been discussing synchronization of data across multiple instances. If someone were willing to define a vocabulary, a RESTful API, and methodology for exposing Consumer-Aggregator-Syndicator services it will benefit the community towards this end.

With that goal in mind, we would like to mentor a bright and motivated student who groks web service oriented architecture. In particular we seek a student who can implement passive synchronization of global, unique IDs over a restful interface.

The implementation should:

  • Be resilient to connection failure.
  • Be able to perform at 4K records (number of 4K records per sec on X-type-pipe) (What's the scale that's reasonable?)
  • Does not need to be a text based API. Binary acceptable.
  • Function in multiple pipes, such as:
    • Cellular
    • dialup
    • WiFi
    • Cable
    • DSL
    • T1
    • T3
    • 10 Gigabit Ethernet

Talking Papers, OCR and a world without data entry

by Chamindra de Silva:

Rather than elaborate here, I would like to point to the excellent blog post by Robert Kirckpatrick that captures this idea http://humanitariantech.com/2009/11/16/talking-papers-a-world-without-data-entry/ and more here http://www.humanitarian.info/2009/11/24/talking-about-paper/

ORM for Sahana Phase II

by Chamindra de Silva

Sahana requires a good ORM. Incorporate the doctrine ORM into the Sahana framework.

Interoperability with InSTEDD RIFF

by Mark Prutsalis

Build two-way interoperability between Sahana's biosurveillance module and InSTEDD RIFF; other general bi-directional integration between InSTEDD GeoChat and Sahana.

Auto-Assignment of Resources

by Charles Wisniewski and Darlene McCullough

Introduction

Upon the creation or activation of a shelter system, the essential administrative task of adequately provisioning these centers becomes pressing. It can be a daunting and time consuming task when there is little time at hand. The timely distribution of volunteers and materials during an already stressful situation can make all the difference in saving a life and preventing further catastrophe.

As part of the logistics module, a dispatch sub-function could be created to automatically distribute and allocate resources; both human and material.

Proposed Wireframe

This is a first pass at a potential wireframe, intended to provide structure and facilitation brainstorming; by no means intended to limit what can be created out of this proposal.

  • At the starting screen you can select what you want to provision. The options include volunteers, materials, or both.
  • To ensure scalability for larger activations:
    • Shelters can be activated by group or individually
    • Resources can be provisioned either as groups or individually.
  • Shelters can be customized to provide special needs:
    • Resources can be categorized to be allocated to these customized shelters
    • Example: A deaf client is sent to a shelter with staff that is fluent in sign language.
    • Example: Insulin donated from a medical provider is auto-assigned to a shelter specializing in elderly clients with diabetes.
  • For deploying resources, the originating location of volunteers and other resources influences the distribution algorithm.
    • Example: Some emergency zones span hundreds of miles and the address or “home” location of a volunteer is considered when deploying them to a shelter.
  • Quality of resources is considered during allocation:
    • Example: The insulin is expired and not distributed.
    • Example: A volunteer is a Certified First Responder and is sent to an emergency medical shelter instead of someone who is only trained in basic first aid.
  • The ability to consume information from a third party logistic information providers.
    • Example: Traffic reports and their affect on resource allocation routes.
    • Example: GIS data in KML (Google maps/earth) format.
  • At the end of the assignment process a report should be generated on-screen indicating where resources have been allocated and the remaining resource pool to be allocated at a later time.

Navigation
  • Navigate