Hi there,
I created a cascading selection form and submitted to ODK aggregate and now
I realize that I need to add another city/province and communities to this
form. I can create an xml form and resubmit. The problem is that when I
resubmit or delete the old form and replace the new edited one, I miss all
the data that my users are collected from the field. Do you have any idea
on how to do this? Thanks for all your support.
I haven't had a chance to test this with the new javarosa libraries and
document how to do this.
If the selection list is in a secondary instance in the form, you should be
able to do this by defining a version attribute alongside the id attribute
in the form definition. The version attribute indicates to Aggregate 1.2
that the form is the same form, but has a user interface change (new
selection choice, change of question text, etc.) As long as the main
instance definition has had no changes in data types or a change in the
number or order of data values captured, it should accept the new form.
I'll look into this next week.
Mitch
Hi there,
I created a cascading selection form and submitted to ODK aggregate and
now I realize that I need to add another city/province and communities to
this form. I can create an xml form and resubmit. The problem is that when
I resubmit or delete the old form and replace the new edited one, I miss
all the data that my users are collected from the field. Do you have any
idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Doea this mean that if i never EXPLICITLY entered an instanceId in my form
in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?
Tumaini
I haven't had a chance to test this with the new javarosa libraries and
document how to do this.If the selection list is in a secondary instance in the form, you should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user interface
change (new selection choice, change of question text, etc.) As long as the
main instance definition has had no changes in data types or a change in
the number or order of data values captured, it should accept the new form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate and
now I realize that I need to add another city/province and communities to
this form. I can create an xml form and resubmit. The problem is that when
I resubmit or delete the old form and replace the new edited one, I miss
all the data that my users are collected from the field. Do you have any
idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
This is the *version *attribute and this update feature is only supported
in ODK Aggregate 1.2. If you have a form with:
and the '/data/mystring' field was a free-form string, and you wanted
to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition,
making this change. To upload it, you
must then also need to add or increment the version string on this
instance (only newer versions can be uploaded):
The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend that the
version string be in the
yyyymmddnn format so that the comparisons work as you would expect.
Mitch
Doea this mean that if i never EXPLICITLY entered an instanceId in my form
in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:I haven't had a chance to test this with the new javarosa libraries and
document how to do this.If the selection list is in a secondary instance in the form, you should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user interface
change (new selection choice, change of question text, etc.) As long as the
main instance definition has had no changes in data types or a change in
the number or order of data values captured, it should accept the new form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate and
now I realize that I need to add another city/province and communities to
this form. I can create an xml form and resubmit. The problem is that when
I resubmit or delete the old form and replace the new edited one, I miss
all the data that my users are collected from the field. Do you have any
idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.
Best regards,
Chan Choth
Adding field in ODK _Research.pdf (542 KB)
Apologize for the typo in this document. I mean:
Conclusion
It is not possible to:
- Add any string field into the form which submitted to ODK
Aggregate
- Add any new location hierarchy into the form which submitted to
ODK Aggregate
Thanks.
On Monday, July 23, 2012 11:35:33 AM UTC+7, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the *version *attribute and this update feature is only
supported in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition, making this change. To upload it, you
must then also need to add or increment the version string on this instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba tkilimba@ihi.or.tzwrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in my
form in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add
an option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:I haven't had a chance to test this with the new javarosa libraries and
document how to do this.If the selection list is in a secondary instance in the form, you
should be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user interface
change (new selection choice, change of question text, etc.) As long as the
main instance definition has had no changes in data types or a change in
the number or order of data values captured, it should accept the new form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.comwrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate
and now I realize that I need to add another city/province and communities
to this form. I can create an xml form and resubmit. The problem is that
when I resubmit or delete the old form and replace the new edited one, I
miss all the data that my users are collected from the field. Do you have
any idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as long as
it would not require any changes to the database. This means that no new
fields may be added in the new version (and, similarly, no old fields may
be deleted and no old fields may have their data types change). Your first
test will clearly not work because you are adding a field. The second test
does work because you are not adding a field but rather are just changing
the UI for the field; this is precisely the use case for which the
new-version support was added.
When it comes to the third test, it seems to me that you are trying to add
fields -- but I don't know anything about these advanced cascading selects,
so I can't be
sure. /Advanced_Cascading_Selection/location_village_in_khnar_sanday, for
example, looks like it is a new field, though you don't highlight its core
instance definition in the second version and don't show the full original
version. You should be able to modify those selects so long as they are
there in the original. Again, though, you can only change the UI, not the
underlying database structure.
It may be, however, that your third change should go through since it does
not actually affect the DB structure. Since I don't understand the syntax
and implementation for those select types, I can't be sure.
Best,
Chris
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the *version *attribute and this update feature is only supported
in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition, making this change. To upload it, you
must then also need to add or increment the version string on this instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba tkilimba@ihi.or.tzwrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in my form
in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:I haven't had a chance to test this with the new javarosa libraries and
document how to do this.If the selection list is in a secondary instance in the form, you should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user interface
change (new selection choice, change of question text, etc.) As long as the
main instance definition has had no changes in data types or a change in
the number or order of data values captured, it should accept the new form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate and
now I realize that I need to add another city/province and communities to
this form. I can create an xml form and resubmit. The problem is that when
I resubmit or delete the old form and replace the new edited one, I miss
all the data that my users are collected from the field. Do you have any
idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en
Dear Chris,
Thanks for your explanation. Is there any possibility that I can change the
database structure? Thanks.
Best regards,
Chan Choth
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as long
as it would not require any changes to the database. This means that no
new fields may be added in the new version (and, similarly, no old fields
may be deleted and no old fields may have their data types change). Your
first test will clearly not work because you are adding a field. The second
test does work because you are not adding a field but rather are just
changing the UI for the field; this is precisely the use case for which the
new-version support was added.When it comes to the third test, it seems to me that you are trying to add
fields -- but I don't know anything about these advanced cascading selects,
so I can't be
sure. /Advanced_Cascading_Selection/location_village_in_khnar_sanday, for
example, looks like it is a new field, though you don't highlight its core
instance definition in the second version and don't show the full original
version. You should be able to modify those selects so long as they are
there in the original. Again, though, you can only change the UI, not the
underlying database structure.It may be, however, that your third change should go through since it does
not actually affect the DB structure. Since I don't understand the syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the *version *attribute and this update feature is only
supported in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition, making this change. To upload it, you
must then also need to add or increment the version string on this instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba tkilimba@ihi.or.tzwrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in my
form in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add
an option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:I haven't had a chance to test this with the new javarosa libraries and
document how to do this.If the selection list is in a secondary instance in the form, you should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user interface
change (new selection choice, change of question text, etc.) As long as the
main instance definition has had no changes in data types or a change in
the number or order of data values captured, it should accept the new form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate and
now I realize that I need to add another city/province and communities to
this form. I can create an xml form and resubmit. The problem is that when
I resubmit or delete the old form and replace the new edited one, I miss
all the data that my users are collected from the field. Do you have any
idea on how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
Dear Chris,
Can you please show me the way on how I could do this? Thanks.
Dear Chris,
I do step 1 and 2. What is Stata? Is it open source software? Do you have
any manual that I could learn from your below process. Thanks.
Hi Chan,
Without heroic coding efforts to automatically port between data
structures, I'm afraid that any database changes will require you to first
delete a form and all its data, then upload the new form. For us in our
projects, actually, this isn't a problem since we download all data into
Stata every day, and maintain our database there. Thus, we don't care about
the data sitting on the Aggregate server and we can replace forms with new
ones as needed (taking care in our Stata import code to account for new or
updated fields). Perhaps you too can design your data processes in such a
way that it's not a big problem to delete the old Aggregate data when
updating forms?
Best,
Chris
Dear Chris,
Thanks for your explanation. Is there any possibility that I can change
the database structure? Thanks.Best regards,
Chan ChothOn Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as long
as it would not require any changes to the database. This means that no
new fields may be added in the new version (and, similarly, no old fields
may be deleted and no old fields may have their data types change). Your
first test will clearly not work because you are adding a field. The second
test does work because you are not adding a field but rather are just
changing the UI for the field; this is precisely the use case for which the
new-version support was added.When it comes to the third test, it seems to me that you are trying to add
fields -- but I don't know anything about these advanced cascading selects,
so I can't be
sure. /Advanced_Cascading_Selection/location_village_in_khnar_sanday, for
example, looks like it is a new field, though you don't highlight its core
instance definition in the second version and don't show the full original
version. You should be able to modify those selects so long as they are
there in the original. Again, though, you can only change the UI, not the
underlying database structure.It may be, however, that your third change should go through since it does
not actually affect the DB structure. Since I don't understand the syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the *version *attribute and this update feature is only supported
in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition, making this change. To upload it, you
must then also need to add or increment the version string on this instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba tkilimba@ihi.or.tzwrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in my form
in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en
Dear Chan,
There is no one method. For our project, we go through a daily routine as
follows:
Use Briefcase to download all form data.
Use Briefcase to decrypt and export all form data to .csv files. (We use
encryption which, really, anybody collecting confidential data and
submitting over 3g should.) (And actually, we download and decrypt on
separate computers since the computer with the private key and confidential
data is permanently disconnected from the network.)
Run a Stata .do file that imports the .csv files, merges them into our
master database of responses (using instanceID as the unique identifier),
and then checks for and reports various errors.
Back up our master database of responses.
With this kind of system, we don't care about the data that accumulates on
Aggregate. Thus, if we have to update a form, we can easily delete it and
upload a new one. (We just have to download all current data first and make
sure that the field teams are not currently collecting data. That generally
means performing updates at night or on weekends, then asking the field
teams to delete and re-download the blank forms.)
There are a great many other ways to organize data management, but I hope
this example helps.
Best,
Chris
Dear Chris,
Can you please show me the way on how I could do this? Thanks.
On Monday, July 23, 2012 1:23:24 PM UTC+7, Chris wrote:
Hi Chan,
Without heroic coding efforts to automatically port between data
structures, I'm afraid that any database changes will require you to first
delete a form and all its data, then upload the new form. For us in our
projects, actually, this isn't a problem since we download all data into
Stata every day, and maintain our database there. Thus, we don't care about
the data sitting on the Aggregate server and we can replace forms with new
ones as needed (taking care in our Stata import code to account for new or
updated fields). Perhaps you too can design your data processes in such a
way that it's not a big problem to delete the old Aggregate data when
updating forms?Best,
Chris
On Monday, July 23, 2012, Chan Choth Puth wrote:
Dear Chris,
Thanks for your explanation. Is there any possibility that I can change
the database structure? Thanks.Best regards,
Chan ChothOn Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as long
as it would not require any changes to the database. This means that no
new fields may be added in the new version (and, similarly, no old fields
may be deleted and no old fields may have their data types change). Your
first test will clearly not work because you are adding a field. The second
test does work because you are not adding a field but rather are just
changing the UI for the field; this is precisely the use case for which the
new-version support was added.When it comes to the third test, it seems to me that you are trying to add
fields -- but I don't know anything about these advanced cascading selects,
so I can't be sure. /Advanced_Cascading_**Selection/location_village_in_**khnar_sanday,
for example, looks like it is a new field, though you don't highlight its
core instance definition in the second version and don't show the full
original version. You should be able to modify those selects so long as
they are there in the original. Again, though, you can only change the UI,
not the underlying database structure.It may be, however, that your third change should go through since it does
not actually affect the DB structure. Since I don't understand the syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the *version *attribute and this update feature is only supported
in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted to change it to a select1, or change the
set of values the select1 showed, you can modify the form definition, making this change. To upload it, you
must then also need to add or increment the version string on this instance (only newer versions can be uploaded):<meta> <ins--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en
Dear Chan,
Stata is the software that we use for data analysis; it is not open source.
I also do not have any manual that I can share, unfortunately.
I would suggest that you consider how it is you will use and analyze the
data. If you use SPSS, merge and maintain the data in SPSS. If you use
Excel, then merge and maintain in Excel. The key is to somewhere maintain a
master record of all responses, and to merge new responses into that master
record using the instanceID to avoid duplicates.
Best,
Chris
Dear Chris,
I do step 1 and 2. What is Stata? Is it open source software? Do you have
any manual that I could learn from your below process. Thanks.On Monday, July 23, 2012 1:37:50 PM UTC+7, Chris wrote:
Dear Chan,
There is no one method. For our project, we go through a daily routine as
follows:
Use Briefcase to download all form data.
Use Briefcase to decrypt and export all form data to .csv files. (We
use encryption which, really, anybody collecting confidential data and
submitting over 3g should.) (And actually, we download and decrypt on
separate computers since the computer with the private key and confidential
data is permanently disconnected from the network.)Run a Stata .do file that imports the .csv files, merges them into our
master database of responses (using instanceID as the unique identifier),
and then checks for and reports various errors.Back up our master database of responses.
With this kind of system, we don't care about the data that accumulates on
Aggregate. Thus, if we have to update a form, we can easily delete it and
upload a new one. (We just have to download all current data first and make
sure that the field teams are not currently collecting data. That generally
means performing updates at night or on weekends, then asking the field
teams to delete and re-download the blank forms.)There are a great many other ways to organize data management, but I hope
this example helps.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Chris,
Can you please show me the way on how I could do this? Thanks.
On Monday, July 23, 2012 1:23:24 PM UTC+7, Chris wrote:
Hi Chan,
Without heroic coding efforts to automatically port between data
structures, I'm afraid that any database changes will require you to first
delete a form and all its data, then upload the new form. For us in our
projects, actually, this isn't a problem since we download all data into
Stata every day, and maintain our database there. Thus, we don't care about
the data sitting on the Aggregate server and we can replace forms with new
ones as needed (taking care in our Stata import code to account for new or
updated fields). Perhaps you too can design your data processes in such a
way that it's not a big problem to delete the old Aggregate data when
updating forms?Best,
Chris
On Monday, July 23, 2012, Chan Choth Puth wrote:
Dear Chris,
Thanks for your explanation. Is there any possibility that I can change
the database structure? Thanks.Best regards,
Chan ChothOn Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as long
as it would not require any changes to the database. This means that no
new fields may be added in the new version (and, similarly, no old fields
may be deleted and no old fields may have their data types change). Your
first test will clearly not work because you are adding a field. The second
test does work because you are not adding a field but rather are just
changing the UI for the field; this is precisely the use case for which the
new-version support was added.When it comes to the third test, it seems to me that you are trying to add
fields -- but I don't know anything about these advanced cascading selects,
so I can't be sure. /Advanced_Cascading_Selection/location_village_in_
khnar_sanday, for example, looks like it is a new field, though you
don't highlight its core instance definition in the second version and
don't show the full original version. You should be able to modify those
selects so long as they are there in the original. Again, though, you can
only change the UI, not the underlying database structure.It may be, however, that your third change should go through since it does
not actually affect the DB structure. Since I don't understand the syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en
It is possible to change the database structure but you have to know
what you are doing (ie execute the custom commands to make the
changes).
Merging data and changing data structures are complex and it's unclear
what default values should be on inserted into an added column or what
should be done when a column is deleted if the column is referenced
elsewhere. Because the "right" answer of how to add or delete a column
is so unique to an application we have not automated the process.
Basically we prefer for people to switch the form ID and start
collecting a second set of data with their updated data structures and
then figure out how to merge their data in their data analysis phase.
It is really hard for the ODK team to predict all use cases.
We are working on ways to make things easier but these new tools will
not be released for a while.
Waylon
Dear Waylon et al,
Actually, I do not want to change the database structure cause there might
be some reference elsewhere that we do not know. The challenges are that:
Best regards,
Chan Choth
See http://opendatakit.org/help/form-design/cascading-selects/
Dear Waylon et al,
Actually, I do not want to change the database structure cause there might
be some reference elsewhere that we do not know. The challenges are that:
- adding new locations (cities or towns and in my case province, district,
communes and villages) are UI- ODK treats location hierarchy as skip logic and database structure
(fields) (Please correct me if I am wrong)Best regards,
Chan ChothOn Monday, July 23, 2012 1:30:19 PM UTC+7, Waylon Brunette wrote:
It is possible to change the database structure but you have to know
what you are doing (ie execute the custom commands to make the
changes).Merging data and changing data structures are complex and it's unclear
what default values should be on inserted into an added column or what
should be done when a column is deleted if the column is referenced
elsewhere. Because the "right" answer of how to add or delete a column
is so unique to an application we have not automated the process.
Basically we prefer for people to switch the form ID and start
collecting a second set of data with their updated data structures and
then figure out how to merge their data in their data analysis phase.
It is really hard for the ODK team to predict all use cases.We are working on ways to make things easier but these new tools will
not be released for a while.Waylon
On Mon, Jul 23, 2012 at 11:47 AM, Chan Choth Puth chanchoth@gmail.com wrote:
Dear Chris,
Thanks for your explanation. Is there any possibility that I can change
the
database structure? Thanks.Best regards,
Chan ChothOn Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert chrislrobert@gmail.com wrote:
Chan,
Mitch will give a more authoritative reply, but let me give it a shot.
Aggregate v1.2 will allow you to upload a new version of a form as
long as
it would not require any changes to the database. This means that no
new
fields may be added in the new version (and, similarly, no old fields
may be
deleted and no old fields may have their data types change). Your
first test
will clearly not work because you are adding a field. The second test
does
work because you are not adding a field but rather are just changing
the UI
for the field; this is precisely the use case for which the
new-version
support was added.When it comes to the third test, it seems to me that you are trying to
add
fields -- but I don't know anything about these advanced cascading
selects,
so I can't be sure.
/Advanced_Cascading_Selection/**location_village_in_khnar_**sanday,
for example,
looks like it is a new field, though you don't highlight its core
instance
definition in the second version and don't show the full original
version.
You should be able to modify those selects so long as they are there
in the
original. Again, though, you can only change the UI, not the
underlying
database structure.It may be, however, that your third change should go through since it
does
not actually affect the DB structure. Since I don't understand the
syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks
for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the version attribute and this update feature is only
supported
in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you wanted
to
change it to a select1, or change theset of values the select1 showed, you can modify the form definition,
making this change. To upload it, you
must then also need to add or increment the version string on this
instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value. ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend
that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba tkilimba@ihi.or.tz wrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in my
form in Aggregate V1.09 but with Aggregate V2.0 i would like to maybe
add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:
I haven't had a chance to test this with the new javarosa libraries
and
document how to do this.If the selection list is in a secondary instance in the form, you
should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates to
Aggregate 1.2 that the form is the same form, but has a user
interface
change (new selection choice, change of question text, etc.) As long
as the
main instance definition has had no changes in data types or a change
in the
number or order of data values captured, it should accept the new
form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate
and
now I realize that I need to add another city/province and
communities to
this form. I can create an xml form and resubmit. The problem is that
when I
resubmit or delete the old form and replace the new edited one, I
miss all
the data that my users are collected from the field. Do you have any
idea on
how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options:--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Dear Mitch,
I follow your advice and be able to do it. The lack of this one is the
label. Please see the attached file of what I mean.
By the way, it works with 4th location hierarchy such as provinces,
districts, communes and villages. Is there any limitation of this one?
Thanks.
Best regards,
Chan Choth
Cascading Selection.pdf (115 KB)
The can have a within it, at the same level as the
. That label is the label for the question. See
http://opendatakit.org/help/form-design/body/ for what the XML file should
look like.
There is no limit to the nesting. We're working on adding this
functionality to XLSForm.
Update: you can simplify the coding of the extra instances using attributes
and '@' to filter and reference on the attribute values:
...
</h:head>
<h:body>
Mitch
Dear Mitch,
I follow your advice and be able to do it. The lack of this one is the
label. Please see the attached file of what I mean.By the way, it works with 4th location hierarchy such as provinces,
districts, communes and villages. Is there any limitation of this one?
Thanks.Best regards,
Chan ChothOn Wednesday, July 25, 2012 1:30:02 AM UTC+7, Mitch wrote:
See http://opendatakit.org/help/**form-design/cascading-selects/http://opendatakit.org/help/form-design/cascading-selects/
On Tue, Jul 24, 2012 at 1:20 AM, Chan Choth chanchoth@gmail.com wrote:
Dear Waylon et al,
Actually, I do not want to change the database structure cause there
might be some reference elsewhere that we do not know. The challenges are
that:
- adding new locations (cities or towns and in my case province,
district, communes and villages) are UI- ODK treats location hierarchy as skip logic and database structure
(fields) (Please correct me if I am wrong)Best regards,
Chan ChothOn Monday, July 23, 2012 1:30:19 PM UTC+7, Waylon Brunette wrote:
It is possible to change the database structure but you have to know
what you are doing (ie execute the custom commands to make the
changes).Merging data and changing data structures are complex and it's unclear
what default values should be on inserted into an added column or what
should be done when a column is deleted if the column is referenced
elsewhere. Because the "right" answer of how to add or delete a column
is so unique to an application we have not automated the process.
Basically we prefer for people to switch the form ID and start
collecting a second set of data with their updated data structures and
then figure out how to merge their data in their data analysis phase.
It is really hard for the ODK team to predict all use cases.We are working on ways to make things easier but these new tools will
not be released for a while.Waylon
On Mon, Jul 23, 2012 at 11:47 AM, Chan Choth Puth chanchoth@gmail.com wrote:
Dear Chris,
Thanks for your explanation. Is there any possibility that I can
change the
database structure? Thanks.Best regards,
Chan ChothOn Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert chrislrobert@gmail.com wrote:
Chan,
Mitch will give a more authoritative reply, but let me give it a
shot.Aggregate v1.2 will allow you to upload a new version of a form as
long as
it would not require any changes to the database. This means that no
new
fields may be added in the new version (and, similarly, no old
fields may be
deleted and no old fields may have their data types change). Your
first test
will clearly not work because you are adding a field. The second
test does
work because you are not adding a field but rather are just changing
the UI
for the field; this is precisely the use case for which the
new-version
support was added.When it comes to the third test, it seems to me that you are trying
to add
fields -- but I don't know anything about these advanced cascading
selects,
so I can't be sure.
/Advanced_Cascading_Selection/****location_village_in_khnar_sanday,
for example,
looks like it is a new field, though you don't highlight its core
instance
definition in the second version and don't show the full original
version.
You should be able to modify those selects so long as they are there
in the
original. Again, though, you can only change the UI, not the
underlying
database structure.It may be, however, that your third change should go through since
it does
not actually affect the DB structure. Since I don't understand the
syntax
and implementation for those select types, I can't be sure.Best,
Chris
On Monday, July 23, 2012, Chan Choth wrote:
Dear Mitch et al,
I tried per your advice and it only works with the simple cascading
selection. Please kindly see the attached file for my test. Thanks
for your
support.Best regards,
Chan ChothOn Saturday, July 21, 2012 12:44:25 AM UTC+7, Mitch wrote:
This is the version attribute and this update feature is only
supported
in ODK Aggregate 1.2. If you have a form with:<meta> <instanceID/> </meta> <mystring/>and the '/data/mystring' field was a free-form string, and you
wanted to
change it to a select1, or change theset of values the select1 showed, you can modify the form
definition,
making this change. To upload it, you
must then also need to add or increment the version string on this
instance (only newer versions can be uploaded):<meta> <instanceID/> </meta> <mystring/>The version string is compared as if it were a string for
determining
whether it is 'newer'. This is because the
OpenRosa standard defines the version string as a string value.
ODK
Aggregate 1.x impose the additional
restriction that this string be an integer value. So we recommend
that
the version string be in the
yyyymmddnn format so that the comparisons work as you would expect.Mitch
On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba < tkilimba@ihi.or.tz> wrote:
Doea this mean that if i never EXPLICITLY entered an instanceId in
my
form in Aggregate V1.09 but with Aggregate V2.0 i would like to
maybe add an
option to a select1 list, i can tjen use this new form with no
incompatibility issues with the previous form?Tumaini
On 20 Jul 2012 19:21, "Mitch S" mitchellsundt@gmail.com wrote:
I haven't had a chance to test this with the new javarosa libraries
and
document how to do this.If the selection list is in a secondary instance in the form, you
should
be able to do this by defining a version attribute alongside the id
attribute in the form definition. The version attribute indicates
to
Aggregate 1.2 that the form is the same form, but has a user
interface
change (new selection choice, change of question text, etc.) As
long as the
main instance definition has had no changes in data types or a
change in the
number or order of data values captured, it should accept the new
form.I'll look into this next week.
Mitch
On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth chanchoth@gmail.com wrote:
Hi there,
I created a cascading selection form and submitted to ODK aggregate
and
now I realize that I need to add another city/province and
communities to
this form. I can create an xml form and resubmit. The problem is
that when I
resubmit or delete the old form and replace the new edited one, I
miss all
the data that my users are collected from the field. Do you have
any idea on
how to do this? Thanks for all your support.--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options:--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@**googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com