open-data-kit - Project Hosting on Google Code

Today 21 hours ago issue 106 (Timeout when exporting data to a Google Spreadsheet) reported by pabloabadsanz - When I want to export a large amount of data form ODK Aggregate's Database to a Google Spreadsheet, by selecting the Upload New Submissions, it takes quite a long time to submit all the rows; and in almost every case, it does not upload all the rows. When I want to export a large amount of data form ODK Aggregate's Database to a Google Spreadsheet, by selecting the Upload New Submissions, it takes quite a long time to submit all the rows; and in almost every case, it does not upload all the rows. Last 7 days Dec 22, 2009 r893 ([No log message]) committed by yanokwa - [No log message] [No log message] Dec 22, 2009 r892 ([No log message]) committed by yanokwa - [No log message] [No log message] Dec 22, 2009 r891 (odk: importing first batch of class projects) committed by yanokwa - odk: importing first batch of class projects odk: importing first batch of class projects Dec 22, 2009 r890 (odk: revert tasks import) committed by yanokwa - odk: revert tasks import odk: revert tasks import Dec 22, 2009 r889 (odk: importing odk tasks) committed by yanokwa - odk: importing odk tasks odk: importing odk tasks Dec 21, 2009 r888 ([No log message]) committed by sthaiya - [No log message] [No log message] Dec 20, 2009 r887 ([No log message]) committed by sthaiya - [No log message] [No log message] Last 30 days Dec 19, 2009 r886 (odk: uw branch) committed by yanokwa - odk: uw branch odk: uw branch Dec 19, 2009 ODKAggregate (Description of ODK Aggregate) Wiki page edited by wbrunette - Revision r885 Edited wiki page through web user interface. Revision r885 Edited wiki page through web user interface. Dec 19, 2009 r884 (update installer to 1.3.0) committed by wbrunette - update installer to 1.3.0 update installer to 1.3.0 Dec 19, 2009 r883 (aggregate: alter Geopoint alt acc proper columns) committed by wbrunette - aggregate: alter Geopoint alt acc proper columns aggregate: alter Geopoint alt acc proper columns Dec 17, 2009 r882 (odk-collect: fix for db names) committed by yanokwa - odk-collect: fix for db names odk-collect: fix for db names Dec 17, 2009 r881 ([No log message]) committed by sthaiya - [No log message] [No log message] Dec 17, 2009 r880 (deleted bin folder) committed by sthaiya - deleted bin folder deleted bin folder Dec 17, 2009 r879 ([No log message]) committed by sthaiya - [No log message] [No log message] Dec 16, 2009 r878 (initial import) committed by sthaiya - initial import initial import Dec 16, 2009 r877 (Initial import.) committed by sthaiya - Initial import. Initial import. Dec 16, 2009 r876 (odk-collect: tagging v1.1.2 release) committed by yanokwa - odk-collect: tagging v1.1.2 release odk-collect: tagging v1.1.2 release Dec 16, 2009 ODK Collect v1.1.2.apk (ODK Collect v1.1.2) file uploaded by yanokwa - Labels: Featured Type-Installer Labels: Featured Type-Installer Dec 15, 2009 r875 (aggregate: add Geopoint alt/acc & form delete beginnings) committed by wbrunette - aggregate: add Geopoint alt/acc & form delete beginnings aggregate: add Geopoint alt/acc & form delete beginnings Dec 12, 2009 r874 (Prevent exception on windows for machines launching with a s...) committed by gary.hendrick - Prevent exception on windows for machines launching with a source directory pointed at a removable drive which no longer exists. Prevent exception on windows for machines launching with a source directory pointed at a removable drive which no longer exists. Dec 11, 2009 r873 (NullPointerException in hasParent() method avoided by testin...) committed by gary.hendrick - NullPointerException in hasParent() method avoided by testing for Null value of parent file NullPointerException in hasParent() method avoided by testing for Null value of parent file Dec 11, 2009 r872 (Downgraded MobileFormEntryModule to be java 1.5 compliant) committed by sthaiya - Downgraded MobileFormEntryModule to be java 1.5 compliant Downgraded MobileFormEntryModule to be java 1.5 compliant Dec 11, 2009 r871 (AMPATH downgraded ODK to be jdk 1.5 compliant) committed by sthaiya - AMPATH downgraded ODK to be jdk 1.5 compliant AMPATH downgraded ODK to be jdk 1.5 compliant Dec 10, 2009 r870 (odk-collect: more french localization) committed by yanokwa - odk-collect: more french localization odk-collect: more french localization Dec 10, 2009 r869 (worked on spaces in concept names) committed by sthaiya - worked on spaces in concept names worked on spaces in concept names Dec 10, 2009 issue 105 (kobo post processor not working) commented on by gary.hendrick - To be clear, when the logger is enabled it will record java logs in the .kobo directory, those are what we'll want to look at. To be clear, when the logger is enabled it will record java logs in the .kobo directory, those are what we'll want to look at. Dec 10, 2009 r868 (Fixed a bug in year of birth calculation) committed by sthaiya - Fixed a bug in year of birth calculation Fixed a bug in year of birth calculation Dec 09, 2009 r867 (odk-collect: localized into french, swahili and chinese) committed by yanokwa - odk-collect: localized into french, swahili and chinese odk-collect: localized into french, swahili and chinese Dec 09, 2009 issue 105 (kobo post processor not working) commented on by gary.hendrick - If there is an exception reported in the console, please add it. If there is not, then we can see how the app is performing by checking logs. There is a settings file under your home directory <Home Directory>/.kobo/kobo.properties inside of this file there is a setting which will control logging levels, PROPKEY_LOGGING_LEVEL = OFF it's default it "OFF" to preserve performance, will you go ahead and change it to "ALL" and run the application again and then attach here. If there is an exception reported in the console, please add it. If there is not, then we can see how the app is performing by checking logs. There is a settings file under your home directory <Home Directory>/.kobo/kobo.properties inside of this file there is a setting which will control logging levels, PROPKEY_LOGGING_LEVEL = OFF it's default it "OFF" to preserve performance, will you go ahead and change it to "ALL" and run the application again and then attach here. Dec 09, 2009 issue 105 (kobo post processor not working) reported by yanokwa - If I open the .jar directly on the desktop, the GUI opens and seems to be working... I can change any three of the directory choices... but when I try either the "sync" or "transcribe" options... nothing happens... the folders I pointed to remain empty. (It does appear that the GUI is "seeing" my SD card with the instances of the saved survey on them, as I can "change XML source directory" to "E:\odk \instances) If I open the .jar directly on the desktop, the GUI opens and seems to be working... I can change any three of the directory choices... but when I try either the "sync" or "transcribe" options... nothing happens... the folders I pointed to remain empty. (It does appear that the GUI is "seeing" my SD card with the instances of the saved survey on them, as I can "change XML source directory" to "E:\odk \instances) Dec 09, 2009 issue 104 (Operate on existing records) reported by yanokwa - I want to be able to take a database, let's say a database of rebel soldiers. The guy comes up to surrender his weapons and participate in a Demobilization process. He says his name, I select him from the database and the survey allows me to add information to his record in the database. Date of surrender, type of weapon turned in, etc. I ask him socio-economic questions and add that to the database. This is a big one, so more thoughts on this later. I want to be able to take a database, let's say a database of rebel soldiers. The guy comes up to surrender his weapons and participate in a Demobilization process. He says his name, I select him from the database and the survey allows me to add information to his record in the database. Date of surrender, type of weapon turned in, etc. I ask him socio-economic questions and add that to the database. This is a big one, so more thoughts on this later. Dec 09, 2009 issue 103 (Cascading selection) reported by yanokwa - If I am recording Country, State, City; it would be super useful to have my answer for country then constraing my choices for State. If I select Florida for State, then I see only cities in Florida in the City question that follows. If I am recording Country, State, City; it would be super useful to have my answer for country then constraing my choices for State. If I select Florida for State, then I see only cities in Florida in the City question that follows. Dec 09, 2009 issue 102 (Font control.) reported by yanokwa - I would really like to be able to change the font size. I would really like to be able to change the font size. Dec 09, 2009 issue 101 (Better Multi-Select data storage) commented on by yanokwa - from clayton "Although the XForms standard we follow doesn't natively support splitting up multi-selects from the form "<radio>2 4 5</radio>", there is a way inside of the xform to have that model generate something like <radio1>1</radio1><radio2>0</radio2> from the "<radio/>" element. The XForms bind supports an attribute called 'calculate' which declaratively defines the value of a node based on an XPath function. Using the 'selected' XPath function, you can then define something like <instance> <model> <radio1/> <radio2/> <radio3/> <tmp> <raw_radio/> </tmp> </model> </instance> <bind nodeset="/model/radio1" calculate="if(selected(/model/tmp/raw_radio,'1'),'1','0'"/> <bind nodeset="/model/radio2" calculate="if(selected(/model/tmp/raw_radio,'2'),'1','0'"/> <bind nodeset="/model/radio3" calculate="if(selected(/model/tmp/raw_radio,'3'),'1','0'"/> ... <select nodeset="model/tmp/raw_radio"> ... <item><lable>WKRP</label><value>1</value></item> <item><lable>WJFD</label><value>2</value></item> <item><lable>WJKS</label><value>3</value></item> </select> Although in some ways this is an onerous solution (one bind per elemenet), it does solve one very important aspect of interpreting multi-select results in that all of the logic and specification remains in the xform and thus can be shared arbitrarily across ODK or OpenRosa implementations. It also has the benefit of being available right now. We do this for some of our very complex xforms and find that it offers a lot of flexibility in defining the underlying data model. Hopefully this is something that is helpful for some ODK'ers out there who are trying to solve similar problems." from clayton "Although the XForms standard we follow doesn't natively support splitting up multi-selects from the form "<radio>2 4 5</radio>", there is a way inside of the xform to have that model generate something like <radio1>1</radio1><radio2>0</radio2> from the "<radio/>" element. The XForms bind supports an attribute called 'calculate' which declaratively defines the value of a node based on an XPath function. Using the 'selected' XPath function, you can then define something like <instance> <model> <radio1/> <radio2/> <radio3/> <tmp> <raw_radio/> </tmp> </model> </instance> <bind nodeset="/model/radio1" calculate="if(selected(/model/tmp/raw_radio,'1'),'1','0'"/> <bind nodeset="/model/radio2" calculate="if(selected(/model/tmp/raw_radio,'2'),'1','0'"/> <bind nodeset="/model/radio3" calculate="if(selected(/model/tmp/raw_radio,'3'),'1','0'"/> ... <select nodeset="model/tmp/raw_radio"> ... <item><lable>WKRP</label><value>1</value></item> <item><lable>WJFD</label><value>2</value></item> <item><lable>WJKS</label><value>3</value></item> </select> Although in some ways this is an onerous solution (one bind per elemenet), it does solve one very important aspect of interpreting multi-select results in that all of the logic and specification remains in the xform and thus can be shared arbitrarily across ODK or OpenRosa implementations. It also has the benefit of being available right now. We do this for some of our very complex xforms and find that it offers a lot of flexibility in defining the underlying data model. Hopefully this is something that is helpful for some ODK'ers out there who are trying to solve similar problems." Dec 09, 2009 issue 101 (Better Multi-Select data storage) reported by yanokwa - Better Multi-Select data storage. This is a funny one, the thing is when you ask a multi-select question, you have a list of items with values like this: What radio stations do you listen to? <item><lable>WKRP</label><value>1</value></item> <item><lable>WJFD</label><value>2</value></item> <item><lable>WJKS</label><value>3</value></item> <item><lable>WMNF</label><value>4</value></item> <item><lable>XKCD</label><value>5</value></item> If you select the first and third, in the XML the data is stored like this: <radio>1 3</radio> So, if I am comparing a bunch of data for this field, my data will look like this: <radio>1 3</radio> <radio>2 4 5</radio> <radio>1</radio> <radio>1 2 3 4</radio> <radio>5</radio> Better Multi-Select data storage. This is a funny one, the thing is when you ask a multi-select question, you have a list of items with values like this: What radio stations do you listen to? <item><lable>WKRP</label><value>1</value></item> <item><lable>WJFD</label><value>2</value></item> <item><lable>WJKS</label><value>3</value></item> <item><lable>WMNF</label><value>4</value></item> <item><lable>XKCD</label><value>5</value></item> If you select the first and third, in the XML the data is stored like this: <radio>1 3</radio> So, if I am comparing a bunch of data for this field, my data will look like this: <radio>1 3</radio> <radio>2 4 5</radio> <radio>1</radio> <radio>1 2 3 4</radio> <radio>5</radio> Dec 09, 2009 CurrentDeployments (List of organizations using ODK tools) Wiki page edited by yanokwa - Revision r866 hrc updates Revision r866 hrc updates Dec 08, 2009 r865 (odk-collect: adding support for google ion) committed by yanokwa - odk-collect: adding support for google ion odk-collect: adding support for google ion Dec 08, 2009 r864 (Collect: added appropriate mime-types to upload.) committed by carlhartung - Collect: added appropriate mime-types to upload. Collect: added appropriate mime-types to upload. Dec 07, 2009 issue 88 (add easier localization support) Status changed by yanokwa - users can add translations to http://spreadsheets.google.com/ccc?key=0AvG9xHyTT648dDladTgzTml3VU5hMUhHckZ5WHFDdUE&hl=en. spanish has been finished. french, italian and swahili are in progress. Status: Fixed users can add translations to http://spreadsheets.google.com/ccc?key=0AvG9xHyTT648dDladTgzTml3VU5hMUhHckZ5WHFDdUE&hl=en. spanish has been finished. french, italian and swahili are in progress. Status: Fixed Dec 07, 2009 r863 (odk-collect: localized into spanish) committed by yanokwa - odk-collect: localized into spanish odk-collect: localized into spanish Dec 07, 2009 r862 (hct odk; minor change) committed by sthaiya - hct odk; minor change hct odk; minor change Dec 06, 2009 issue 100 (Adding amateur radio in ODK?) reported by sko...@eunet.rs - It makes me wonder if ODK approach could be implemented for media other than mobile phone systems? For example, I am a long-term amateur radio practitioner and I am used to one of our digital systems of communicating that is called 'packet radio' -- connecting computers by the amateur radio infrastructure. It looks to me that possible implementing of either ODK for usage in the amateur radio systems, or if not viable, transmitting collected data sheets in electronic format, (which might be eventually compatible with ODK databases), might be a valuable supplement to exchanging (health or any other) data via cellular systems. Of course, the amateur radio systems are not going to be, and they have never tried to be, an opponent to commercial systems like big telecoms, incl. cellular providers. On the other hand, amateur (also called 'ham') radio technologies offer something that commercial systems prefer not to do: An opportunity to build your infrastructure on your own and, in the same time, to increase your knowledge in electrical and other sorts of engineering (mechanical, civil, etc). That specific feature of the amateur radio that distinguish an average consumer, i.e. user of a commercial systems of, say, mobile telephonies or like, from devoted radio amateur enthusiasts who are going to project, build and later maintenance their own local and global wireless infrastructure, might be an interesting added-value option to what the authors proposed in the article. I mean, many rural and developing regions not only lack of proper health prevention and treatment, or good environment protection, and similar issues mentioned in the article, but also experience lower levels of capabilities in exchanging engineering knowledge, as well as comparing educational ideas and practice, etc, with the rest of the world, particularly with developed parts of it. The amateur radio proved long ago that even the state heads, like Spanish King Carlos or late Jordanian King Hussein, can operate those non-for-profit ham radio systems and communicate unknown correspondents on the other end -- wherever they live and whoever they are. In that manner, eventual adoption of ODK (or any other similar approach) to existing amateur radio system, -or- implementing them both in parallel or simultaneous way, could not only increase the level of mentioned health and environmental protection efforts, but to support electrical, mechanical and otherwise engineering abilities in developing nations. For example, and as long as I know, there exist various amateur radio groups at many US universities, so they might be attracted to join the ODK project. Miroslav Skoric It makes me wonder if ODK approach could be implemented for media other than mobile phone systems? For example, I am a long-term amateur radio practitioner and I am used to one of our digital systems of communicating that is called 'packet radio' -- connecting computers by the amateur radio infrastructure. It looks to me that possible implementing of either ODK for usage in the amateur radio systems, or if not viable, transmitting collected data sheets in electronic format, (which might be eventually compatible with ODK databases), might be a valuable supplement to exchanging (health or any other) data via cellular systems. Of course, the amateur radio systems are not going to be, and they have never tried to be, an opponent to commercial systems like big telecoms, incl. cellular providers. On the other hand, amateur (also called 'ham') radio technologies offer something that commercial systems prefer not to do: An opportunity to build your infrastructure on your own and, in the same time, to increase your knowledge in electrical and other sorts of engineering (mechanical, civil, etc). That specific feature of the amateur radio that distinguish an average consumer, i.e. user of a commercial systems of, say, mobile telephonies or like, from devoted radio amateur enthusiasts who are going to project, build and later maintenance their own local and global wireless infrastructure, might be an interesting added-value option to what the authors proposed in the article. I mean, many rural and developing regions not only lack of proper health prevention and treatment, or good environment protection, and similar issues mentioned in the article, but also experience lower levels of capabilities in exchanging engineering knowledge, as well as comparing educational ideas and practice, etc, with the rest of the world, particularly with developed parts of it. The amateur radio proved long ago that even the state heads, like Spanish King Carlos or late Jordanian King Hussein, can operate those non-for-profit ham radio systems and communicate unknown correspondents on the other end -- wherever they live and whoever they are. In that manner, eventual adoption of ODK (or any other similar approach) to existing amateur radio system, -or- implementing them both in parallel or simultaneous way, could not only increase the level of mentioned health and environmental protection efforts, but to support electrical, mechanical and otherwise engineering abilities in developing nations. For example, and as long as I know, there exist various amateur radio groups at many US universities, so they might be attracted to join the ODK project. Miroslav Skoric Dec 05, 2009 r861 (odk-aggregate: Fix jar mistake) committed by wbrunette - odk-aggregate: Fix jar mistake odk-aggregate: Fix jar mistake Dec 04, 2009 r860 (odk-collect: tweak tab font size) committed by yanokwa - odk-collect: tweak tab font size odk-collect: tweak tab font size Dec 04, 2009 r859 (- Ported more to database (i.e. instances, instance binaries...) committed by adam.lerer - - Ported more to database (i.e. instances, instance binaries) - Added (untested) change language features. - Ported more to database (i.e. instances, instance binaries) - Added (untested) change language features. Dec 03, 2009 r858 (new hct form) committed by sthaiya - new hct form new hct form Dec 03, 2009 r857 (HCT OpenMRS module- Error Resolution together with household...) committed by sthaiya - HCT OpenMRS module- Error Resolution together with household-patient link. HCT OpenMRS module- Error Resolution together with household-patient link. Dec 03, 2009 r856 (Post resource-bundle-ification.) committed by adam.lerer - Post resource-bundle-ification. Post resource-bundle-ification.

issue 100 (Adding amateur radio in ODK?) reported by sko...@eunet.rs - It makes me wonder if ODK approach could be implemented for media other than mobile phone systems? For example, I am a long-term amateur radio practitioner and I am used to one of our digital systems of communicating that is called 'packet radio' -- connecting computers by the amateur radio infrastructure. It looks to me that possible implementing of either ODK for usage in the amateur radio systems, or if not viable, transmitting collected data sheets in electronic format, (which might be eventually compatible with ODK databases), might be a valuable supplement to exchanging (health or any other) data via cellular systems. Of course, the amateur radio systems are not going to be, and they have never tried to be, an opponent to commercial systems like big telecoms, incl. cellular providers. On the other hand, amateur (also called 'ham') radio technologies offer something that commercial systems prefer not to do: An opportunity to build your infrastructure on your own and, in the same time, to increase your knowledge in electrical and other sorts of engineering (mechanical, civil, etc). That specific feature of the amateur radio that distinguish an average consumer, i.e. user of a commercial systems of, say, mobile telephonies or like, from devoted radio amateur enthusiasts who are going to project, build and later maintenance their own local and global wireless infrastructure, might be an interesting added-value option to what the authors proposed in the article. I mean, many rural and developing regions not only lack of proper health prevention and treatment, or good environment protection, and similar issues mentioned in the article, but also experience lower levels of capabilities in exchanging engineering knowledge, as well as comparing educational ideas and practice, etc, with the rest of the world, particularly with developed parts of it. The amateur radio proved long ago that even the state heads, like Spanish King Carlos or late Jordanian King Hussein, can operate those non-for-profit ham radio systems and communicate unknown correspondents on the other end -- wherever they live and whoever they are. In that manner, eventual adoption of ODK (or any other similar approach) to existing amateur radio system, -or- implementing them both in parallel or simultaneous way, could not only increase the level of mentioned health and environmental protection efforts, but to support electrical, mechanical and otherwise engineering abilities in developing nations. For example, and as long as I know, there exist various amateur radio groups at many US universities, so they might be attracted to join the ODK project. Miroslav Skoric

It makes me wonder if ODK approach could be implemented for media other than mobile phone systems? For example, I am a long-term amateur radio practitioner and I am used to one of our digital systems of communicating that is called 'packet radio' -- connecting computers by the amateur radio infrastructure. It looks to me that possible implementing of either ODK for usage in the amateur radio systems, or if not viable, transmitting collected data sheets in electronic format, (which might be eventually compatible with ODK databases), might be a valuable supplement to exchanging (health or any other) data via cellular systems. Of course, the amateur radio systems are not going to be, and they have never tried to be, an opponent to commercial systems like big telecoms, incl. cellular providers. On the other hand, amateur (also called 'ham') radio technologies offer something that commercial systems prefer not to do: An opportunity to build your infrastructure on your own and, in the same time, to increase your knowledge in electrical and other sorts of engineering (mechanical, civil, etc). That specific feature of the amateur radio that distinguish an average consumer, i.e. user of a commercial systems of, say, mobile telephonies or like, from devoted radio amateur enthusiasts who are going to project, build and later maintenance their own local and global wireless infrastructure, might be an interesting added-value option to what the authors proposed in the article. I mean, many rural and developing regions not only lack of proper health prevention and treatment, or good environment protection, and similar issues mentioned in the article, but also experience lower levels of capabilities in exchanging engineering knowledge, as well as comparing educational ideas and practice, etc, with the rest of the world, particularly with developed parts of it. The amateur radio proved long ago that even the state heads, like Spanish King Carlos or late Jordanian King Hussein, can operate those non-for-profit ham radio systems and communicate unknown correspondents on the other end -- wherever they live and whoever they are. In that manner, eventual adoption of ODK (or any other similar approach) to existing amateur radio system, -or- implementing them both in parallel or simultaneous way, could not only increase the level of mentioned health and environmental protection efforts, but to support electrical, mechanical and otherwise engineering abilities in developing nations. For example, and as long as I know, there exist various amateur radio groups at many US universities, so they might be attracted to join the ODK project. Miroslav Skoric

Today

Last 7 days

Last 30 days