Differences

This shows you the differences between two versions of the page.

dev:sahana_gsoc10_ideas [2010/03/09 10:46]
nishantha
dev:sahana_gsoc10_ideas [2010/05/10 19:02] (current)
glenn
Line 182: Line 182:
Or suppliers? 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. 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==== ==== Sahana Reporting Module====
-By Nishantha Pradeep 
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.   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.  
Line 193: Line 191:
SKILLS REQUIRED: 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.
 +
 +For more see [[dev:Agasti_Module_Manager | the page for this project]]
 +
 +====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 [[http://www.fema.gov/about/programs/disastermanagement/standards/edxl-tep.shtm | FEMA's EDXL-TEP Site]]
 +
 +Pertinent documents (both overview and technical) are [[http://www.evotecinc.com/TEP/ | 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  ====
 +
 +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