Editing cascading selection form?

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

··· On Thu, Jul 19, 2012 at 7:43 PM, Chan Choth 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

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" 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

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

··· On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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.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)

··· On 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: > > > > > > > > > > > > > > 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 > > On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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" 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 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 >

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 Choth

On 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

··· 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 Choth

On 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

··· On 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 Choth

On 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.

··· 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 Choth >> >> On 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 Choth >> >> On 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: >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 >> >> On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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 >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >

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: > > 1. Use Briefcase to download all form data. > > 2. 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.) > > 3. 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. > > 4. 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 Choth >> >> On 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 Choth >> >> On 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: >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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): >> >> >> >> >> >> >> >> >> >> >> >> >> > >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >

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 Choth

On 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 Choth

On 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:

  1. Use Briefcase to download all form data.

  2. 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.)

  3. 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.

  4. 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 Choth

On 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 Choth

On 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

··· On Monday, July 23, 2012, Chan Choth wrote:

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:

  1. Use Briefcase to download all form data.

  2. 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.)

  3. 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.

  4. 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 Choth

On 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

··· On Mon, Jul 23, 2012 at 11:47 AM, 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 Choth > > > On Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert 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 Choth >>> >>> On 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: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 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 >>> >>> On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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" 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 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: >>> >>> -- >>> 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 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 Choth

··· On 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 wrote: > > Dear Chris, > > > > Thanks for your explanation. Is there any possibility that I can change > the > > database structure? Thanks. > > > > Best regards, > > Chan Choth > > > > > > On Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert 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 Choth > >>> > >>> On 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: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 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 > >>> > >>> On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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" 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 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: > >>> > >>> -- > >>> 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 >

See http://opendatakit.org/help/form-design/cascading-selects/

··· On Tue, Jul 24, 2012 at 1:20 AM, Chan Choth 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 Choth

On 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 Choth

On 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 Choth

On 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.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)

··· On Wednesday, July 25, 2012 1:30:02 AM UTC+7, Mitch wrote: > > See http://opendatakit.org/help/form-design/cascading-selects/ > > On Tue, Jul 24, 2012 at 1:20 AM, Chan Choth 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 Choth >> >> >> On 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 wrote: >>> > Dear Chris, >>> > >>> > Thanks for your explanation. Is there any possibility that I can >>> change the >>> > database structure? Thanks. >>> > >>> > Best regards, >>> > Chan Choth >>> > >>> > >>> > On Mon, Jul 23, 2012 at 12:00 PM, Christopher Robert 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 Choth >>> >>> >>> >>> On 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: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 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 >>> >>> >>> >>> On Fri, Jul 20, 2012 at 9:51 AM, Tumaini Kilimba 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" 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 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: >>> >>> >>> >>> -- >>> >>> 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 >>> >> -- >> 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 >

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

··· On Wed, Jul 25, 2012 at 1:38 AM, Chan Choth wrote:

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

On 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 Choth

On 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 Choth

On 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 Choth

On 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.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