| 51 | | * Use ODK Collect to acquire photographic data through a form on the mobile client |
| 52 | | * Store images on the mobile device until a connection can be made to the server |
| 53 | | * Provide an interface in Sahana through which users can access ODK Collect to upload photos |
| 54 | | * Handle image storage on the server side when a user uploads a photo |
| | 55 | * Generate appropriate XForms from image_id fields |
| | 56 | * [http://code.google.com/p/opendatakit/source/browse/Geo+Tagger.xml?repo=forms&r=34910a944c745232d285d2caecf876c3dcae9674 GeoTagger] is a sample Form for ODK which can be used as a template for what needs to be produced by {{{controllers/xforms.py}}} |
| | 57 | * Provide an interface in Sahana through which users can submit these images via ODK Collect & have them stored (in the doc_image table, referenced by the image_id foreign key) |
| | 58 | * {{{controllers/xforms.py}}} |
| | 59 | * ideally use an XSLT to convert the XForm to S3XML |
| 57 | | * Send GPS Coordinates |
| 58 | | * [http://code.google.com/p/opendatakit/source/browse/Geo+Tagger.xml?repo=forms&r=34910a944c745232d285d2caecf876c3dcae9674 GeoTagger] is a sample Form for ODK which can be used as a template for what needs to be produced by {{{controllers/xforms.py}}} from location_id & image_id fields. |
| 59 | | * We also need {{{controllers/xforms.py}}} to be able to parse the form back. |
| 60 | | * Currently the ODK Collect client seems to only be able to use GPS for location rather than a wireless fix, which could use fixing (Sahana's Location should have the lower accuracy marker: either source or ce fields). |
| 61 | | * http://developer.android.com/guide/topics/location/obtaining-user-location.html |
| | 62 | * Send Location Coordinates |
| | 63 | * Generate appropriate XForms from location_id fields |
| | 64 | * [http://code.google.com/p/opendatakit/source/browse/Geo+Tagger.xml?repo=forms&r=34910a944c745232d285d2caecf876c3dcae9674 GeoTagger] is a sample Form for ODK which can be used as a template for what needs to be produced by {{{controllers/xforms.py}}} |
| | 65 | * Provide an interface in Sahana through which users can submit these coordinates via ODK Collect & have them stored (in the gis_location table, referenced by the location_id foreign key) |
| | 66 | * {{{controllers/xforms.py}}} |
| | 67 | * ideally use an XSLT to convert the XForm to S3XML |
| | 68 | * Sahana's Location should have the lower accuracy marked when fix was obtained wirelessly: either source or ce fields (ideally the latter if we have a numeric value available). |
| 65 | | * SMS: There are 2 APIs for sending SMS. 1 of which automatically splits up larger messages into multi-part SMS. |
| 66 | | * This SMS API should be investigated, and possibly included in ODK Collect: http://bitbucket.org/javarosa/javarosa/wiki/SMSSendingAPI |
| 67 | | * NCSU has produced some initial ODK Collect code for SMS. |
| 68 | | * This currently sends an SMS whenever an HTTP transmission attempt fails |
| 69 | | * ~~Still need prompt if the HTTP submission fails.~~ |
| 70 | | * Needs to work on the Sahana server side with more than just the controllers.msg.tropo() method (like sms_handler_modem) |
| 71 | | * Need some way to verify that a whole form submission was successful (esp. for multi-part SMS). |
| 72 | | * Need to delete the submitted form from the mobile device when it the submission was confirmed successful. |
| 73 | | * The current multi-part transmission uses a very proprietary sequence number and unique id system that looks like this, and needs to be fixed in a less proprietary way: |
| 74 | | * (1/3)(12345) |
| 75 | | * ... |
| 76 | | * (3/3)(12345) |
| 77 | | * ...This method required a change in the ODK Collect code, and in the Sahana, which is why only the tropo code path can rebuild SMS somehow. |
| | 72 | * SMS (building on the current NCSU code) |
| | 73 | * Investigate the [http://bitbucket.org/javarosa/javarosa/wiki/SMSSendingAPI OpenRosa SMS API] |
| | 74 | * Needs to work on the Sahana server side with more than just the controllers.msg.tropo() method (like sms_handler_modem) |
| | 75 | * Need some way to verify that a whole form submission was successful (esp. for multi-part SMS). |
| | 76 | * Need to delete the submitted form from the mobile device when it the submission was confirmed successful. |
| | 77 | * The [MobileAndroid#SMSStructure current multi-part transmission] uses a very custom sequence number, which should be made more standard (& take up less room) |
| | 78 | * Need to compress the form submissions |
