Tap counter

Dear ODK community,

I am developing a survey for forest enumeration as part of a REDD project.
One of the key biomass parameters are shrubs. Our current methodology
simply records the shrub and places it into a size class based on the
height of the shrub (small: Below knee height, medium: knee to shoulder,
large: above shoulder). In practice a field plot technician walks around
the plot and calls out the sizes as he encounters the shrubs, another field
technician then records the number of shrubs per size group. Currently, I
have a "begin repeat" with a select_one inside giving the technician the
option to select either small medium or large. This should work but
presents a couple of issues.

  1. The begin repeat will create a separate table on aggregate which is
    problematic for automating data processing later on. I am sure this can be
    overcome with some javascripting online but would prefer the number of each
    shrub be recorded in the main table.

  2. Secondly, the "would you like to add another" option can be problematic
    in the field.

My question is thus, is there an option where I split the input screen into
three sections one for each size class. The technician will then have the
option of tapping a size class to record an occurrence. The table would
then contain three name variables (three size groups) with the number of
shrubs recorded in each.

Many thanks and looking forward to your responses,
Regards
Wes

Several groups (corey@servalproject.org , prabhas.pokharel@gmail.com ) have
asked for 'group-of-data-values' submissions using custom external apps to
gather the data.

I don't have time to implement this, but I've referred everyone to this
plan:
http://code.google.com/p/opendatakit/wiki/XFormControlExtensionProposal

With this approach, you could write your own 'tap' app that had 3 buttons,
and returned 3 data values into the form.

Perhaps the teams that need this could pool their resources and submit a
patch?

Mitch

··· On Wed, Sep 19, 2012 at 2:54 AM, Wes Roberts wrote:

Dear ODK community,

I am developing a survey for forest enumeration as part of a REDD project.
One of the key biomass parameters are shrubs. Our current methodology
simply records the shrub and places it into a size class based on the
height of the shrub (small: Below knee height, medium: knee to shoulder,
large: above shoulder). In practice a field plot technician walks around
the plot and calls out the sizes as he encounters the shrubs, another field
technician then records the number of shrubs per size group. Currently, I
have a "begin repeat" with a select_one inside giving the technician the
option to select either small medium or large. This should work but
presents a couple of issues.

  1. The begin repeat will create a separate table on aggregate which is
    problematic for automating data processing later on. I am sure this can be
    overcome with some javascripting online but would prefer the number of each
    shrub be recorded in the main table.

  2. Secondly, the "would you like to add another" option can be problematic
    in the field.

My question is thus, is there an option where I split the input screen
into three sections one for each size class. The technician will then have
the option of tapping a size class to record an occurrence. The table would
then contain three name variables (three size groups) with the number of
shrubs recorded in each.

Many thanks and looking forward to your responses,
Regards
Wes

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

I should also add that currently you can launch an external android app
from collect but right now it can only accept one value back. The launch of
the external android app is mapped to a single question which in xforms
maps to a single value. Here are some links to previous threads on it.

http://groups.google.com/group/opendatakit/browse_thread/thread/88fc497a01c99e78/cb15c9de739a554a?lnk=gst&q=launch+external+app#cb15c9de739a554a

http://groups.google.com/group/opendatakit/browse_thread/thread/1e4555d0e969e3cd/37d319b148a0f381?lnk=gst&q=launching+external+app#37d319b148a0f381

As a quick hack you could have the 3 values returned as a string (need to
use string type) do some parsing on that string after the submission. For
example you could encode the string with a key value pairs. An example
could be 'small=12;medium=34;large=2'. You would then need to parse this
information once exported.

This is being fixed in the ODK 2.0 toolset where you can map a widget to
any number of values/questions in the form. However, with xforms and
javarosa they like one value per question and we have not figured out how
we would want to work around that. Examples like GPS and Multi-select still
have one answer value that requires special parsing similar to what is
suggested above.

Hope this was helpful explaining the constraints.

Waylon

··· On Wed, Sep 19, 2012 at 11:09 AM, Mitch S wrote:

Several groups (corey@servalproject.org , prabhas.pokharel@gmail.com )have asked for 'group-of-data-values' submissions using custom external
apps to gather the data.

I don't have time to implement this, but I've referred everyone to this
plan:
http://code.google.com/p/opendatakit/wiki/XFormControlExtensionProposal

With this approach, you could write your own 'tap' app that had 3 buttons,
and returned 3 data values into the form.

Perhaps the teams that need this could pool their resources and submit a
patch?

Mitch

On Wed, Sep 19, 2012 at 2:54 AM, Wes Roberts jwesroberts@gmail.comwrote:

Dear ODK community,

I am developing a survey for forest enumeration as part of a REDD
project. One of the key biomass parameters are shrubs. Our current
methodology simply records the shrub and places it into a size class based
on the height of the shrub (small: Below knee height, medium: knee to
shoulder, large: above shoulder). In practice a field plot technician walks
around the plot and calls out the sizes as he encounters the shrubs,
another field technician then records the number of shrubs per size group.
Currently, I have a "begin repeat" with a select_one inside giving the
technician the option to select either small medium or large. This should
work but presents a couple of issues.

  1. The begin repeat will create a separate table on aggregate which is
    problematic for automating data processing later on. I am sure this can be
    overcome with some javascripting online but would prefer the number of each
    shrub be recorded in the main table.

  2. Secondly, the "would you like to add another" option can be
    problematic in the field.

My question is thus, is there an option where I split the input screen
into three sections one for each size class. The technician will then have
the option of tapping a size class to record an occurrence. The table would
then contain three name variables (three size groups) with the number of
shrubs recorded in each.

Many thanks and looking forward to your responses,
Regards
Wes

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

Dear Mitch and Waylon,

Many thanks for your inputs and info.

I agree, perhaps we can pool our abilities and add the functionality to
ODK, Would be great to learn more about the development side of things. The
groups mentioned have been copied to email.

I still need to get my head around the launching of an external app but I
see this as being beneficial especially for measuring the height of trees.
I like the idea of using a string of numbers and simply counting the
occurence post form upload. Lets say for example small is 1, medium is 2,
large is 3 - an input could look something like this shrubs:
11111222221111131111333222. Also inputs could be constrained to .<4 or
something like that. For this to work the input screen would need to be
numbers only, will need to see if this is possible and what the maximum
length of string / integer is.

Thanks for the ideas, our form is still a long way off being operational so
we have time to test and develop.

Regards and thanks for the wonderful application, this is really going to
speed up data collection and processing.

Regards,
Wesley

··· On Wednesday, September 19, 2012 9:27:02 PM UTC+2, Waylon Brunette wrote: > > I should also add that currently you can launch an external android app > from collect but right now it can only accept one value back. The launch of > the external android app is mapped to a single question which in xforms > maps to a single value. Here are some links to previous threads on it. > > > http://groups.google.com/group/opendatakit/browse_thread/thread/88fc497a01c99e78/cb15c9de739a554a?lnk=gst&q=launch+external+app#cb15c9de739a554a > > > http://groups.google.com/group/opendatakit/browse_thread/thread/1e4555d0e969e3cd/37d319b148a0f381?lnk=gst&q=launching+external+app#37d319b148a0f381 > > As a quick hack you could have the 3 values returned as a string (need to > use string type) do some parsing on that string after the submission. For > example you could encode the string with a key value pairs. An example > could be 'small=12;medium=34;large=2'. You would then need to parse this > information once exported. > > This is being fixed in the ODK 2.0 toolset where you can map a widget to > any number of values/questions in the form. However, with xforms and > javarosa they like one value per question and we have not figured out how > we would want to work around that. Examples like GPS and Multi-select still > have one answer value that requires special parsing similar to what is > suggested above. > > Hope this was helpful explaining the constraints. > > Waylon > > > On Wed, Sep 19, 2012 at 11:09 AM, Mitch S wrote: > >> Several groups (corey@servalproject.org , prabhas.pokharel@gmail.com )have asked for 'group-of-data-values' submissions using custom external >> apps to gather the data. >> >> I don't have time to implement this, but I've referred everyone to this >> plan: >> http://code.google.com/p/opendatakit/wiki/XFormControlExtensionProposal >> >> With this approach, you could write your own 'tap' app that had 3 >> buttons, and returned 3 data values into the form. >> >> Perhaps the teams that need this could pool their resources and submit a >> patch? >> >> Mitch >> >> >> On Wed, Sep 19, 2012 at 2:54 AM, Wes Roberts wrote: >> >>> Dear ODK community, >>> >>> I am developing a survey for forest enumeration as part of a REDD >>> project. One of the key biomass parameters are shrubs. Our current >>> methodology simply records the shrub and places it into a size class based >>> on the height of the shrub (small: Below knee height, medium: knee to >>> shoulder, large: above shoulder). In practice a field plot technician walks >>> around the plot and calls out the sizes as he encounters the shrubs, >>> another field technician then records the number of shrubs per size group. >>> Currently, I have a "begin repeat" with a select_one inside giving the >>> technician the option to select either small medium or large. This should >>> work but presents a couple of issues. >>> >>> 1. The begin repeat will create a separate table on aggregate which is >>> problematic for automating data processing later on. I am sure this can be >>> overcome with some javascripting online but would prefer the number of each >>> shrub be recorded in the main table. >>> >>> 2. Secondly, the "would you like to add another" option can be >>> problematic in the field. >>> >>> My question is thus, is there an option where I split the input screen >>> into three sections one for each size class. The technician will then have >>> the option of tapping a size class to record an occurrence. The table would >>> then contain three name variables (three size groups) with the number of >>> shrubs recorded in each. >>> >>> Many thanks and looking forward to your responses, >>> Regards >>> Wes >>> >>> -- >>> 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 >> > >

If you're storing a long list of digits in a string, keep in mind that ODK
Aggregate has storage limitations -- it will truncate any string to 256
characters unless you specify an explicit maximum string length -- see
http://opendatakit.org/help/form-design/guidelines/ at the bottom of the
page ( Datastore String Length ). This is a limit in ODK Aggregate. I do
not believe ODK Collect imposes any meaningful limit on the length of
strings it can record.

Mitch

··· On Wed, Sep 19, 2012 at 11:37 PM, Wes Roberts wrote:

Dear Mitch and Waylon,

Many thanks for your inputs and info.

I agree, perhaps we can pool our abilities and add the functionality to
ODK, Would be great to learn more about the development side of things. The
groups mentioned have been copied to email.

I still need to get my head around the launching of an external app but I
see this as being beneficial especially for measuring the height of trees.
I like the idea of using a string of numbers and simply counting the
occurence post form upload. Lets say for example small is 1, medium is 2,
large is 3 - an input could look something like this shrubs:
11111222221111131111333222. Also inputs could be constrained to .<4 or
something like that. For this to work the input screen would need to be
numbers only, will need to see if this is possible and what the maximum
length of string / integer is.

Thanks for the ideas, our form is still a long way off being operational
so we have time to test and develop.

Regards and thanks for the wonderful application, this is really going to
speed up data collection and processing.

Regards,
Wesley

On Wednesday, September 19, 2012 9:27:02 PM UTC+2, Waylon Brunette wrote:

I should also add that currently you can launch an external android app
from collect but right now it can only accept one value back. The launch of
the external android app is mapped to a single question which in xforms
maps to a single value. Here are some links to previous threads on it.

http://groups.google.com/**group/opendatakit/browse_thread/thread/
88fc497a01c99e78/**cb15c9de739a554a?lnk=gst&q=launch+external+app#
cb15c9de739a554ahttp://groups.google.com/group/opendatakit/browse_thread/thread/88fc497a01c99e78/cb15c9de739a554a?lnk=gst&q=launch+external+app#cb15c9de739a554a

http://groups.google.com/**group/opendatakit/browse_thread/thread/
1e4555d0e969e3cd/**37d319b148a0f381?lnk=gst&q=launching+external+app#
37d319b148a0f381http://groups.google.com/group/opendatakit/browse_thread/thread/1e4555d0e969e3cd/37d319b148a0f381?lnk=gst&q=launching+external+app#37d319b148a0f381

As a quick hack you could have the 3 values returned as a string (need to
use string type) do some parsing on that string after the submission. For
example you could encode the string with a key value pairs. An example
could be 'small=12;medium=34;large=2'. You would then need to parse this
information once exported.

This is being fixed in the ODK 2.0 toolset where you can map a widget to
any number of values/questions in the form. However, with xforms and
javarosa they like one value per question and we have not figured out how
we would want to work around that. Examples like GPS and Multi-select still
have one answer value that requires special parsing similar to what is
suggested above.

Hope this was helpful explaining the constraints.

Waylon

On Wed, Sep 19, 2012 at 11:09 AM, Mitch S mitchellsundt@gmail.comwrote:

Several groups (corey@servalproject.org , prabhas.pokharel@gmail.com )have asked for 'group-of-data-values' submissions using custom external
apps to gather the data.

I don't have time to implement this, but I've referred everyone to this
plan: http://code.google.com/p/opendatakit/wiki/
XFormControlExtensionProposalhttp://code.google.com/p/opendatakit/wiki/XFormControlExtensionProposal

With this approach, you could write your own 'tap' app that had 3
buttons, and returned 3 data values into the form.

Perhaps the teams that need this could pool their resources and submit a
patch?

Mitch

On Wed, Sep 19, 2012 at 2:54 AM, Wes Roberts jwesroberts@gmail.comwrote:

Dear ODK community,

I am developing a survey for forest enumeration as part of a REDD
project. One of the key biomass parameters are shrubs. Our current
methodology simply records the shrub and places it into a size class based
on the height of the shrub (small: Below knee height, medium: knee to
shoulder, large: above shoulder). In practice a field plot technician walks
around the plot and calls out the sizes as he encounters the shrubs,
another field technician then records the number of shrubs per size group.
Currently, I have a "begin repeat" with a select_one inside giving the
technician the option to select either small medium or large. This should
work but presents a couple of issues.

  1. The begin repeat will create a separate table on aggregate which is
    problematic for automating data processing later on. I am sure this can be
    overcome with some javascripting online but would prefer the number of each
    shrub be recorded in the main table.

  2. Secondly, the "would you like to add another" option can be
    problematic in the field.

My question is thus, is there an option where I split the input screen
into three sections one for each size class. The technician will then have
the option of tapping a size class to record an occurrence. The table would
then contain three name variables (three size groups) with the number of
shrubs recorded in each.

Many thanks and looking forward to your responses,
Regards
Wes

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

Many thanks Mitch,

We have some hardcopy data sheets from previous sampling campaigns which I
will use to determine the string length required. I doubt we will encounter
a plot with more than 256 shrubs.

Regards,
Wesley

··· On Thu, Sep 20, 2012 at 7:58 PM, Mitch S wrote:

If you're storing a long list of digits in a string, keep in mind that ODK
Aggregate has storage limitations -- it will truncate any string to 256
characters unless you specify an explicit maximum string length -- see
http://opendatakit.org/help/form-design/guidelines/ at the bottom of the
page ( Datastore String Length ). This is a limit in ODK Aggregate. I do
not believe ODK Collect imposes any meaningful limit on the length of
strings it can record.

Mitch

On Wed, Sep 19, 2012 at 11:37 PM, Wes Roberts jwesroberts@gmail.comwrote:

Dear Mitch and Waylon,

Many thanks for your inputs and info.

I agree, perhaps we can pool our abilities and add the functionality to
ODK, Would be great to learn more about the development side of things. The
groups mentioned have been copied to email.

I still need to get my head around the launching of an external app but I
see this as being beneficial especially for measuring the height of trees.
I like the idea of using a string of numbers and simply counting the
occurence post form upload. Lets say for example small is 1, medium is 2,
large is 3 - an input could look something like this shrubs:
11111222221111131111333222. Also inputs could be constrained to .<4 or
something like that. For this to work the input screen would need to be
numbers only, will need to see if this is possible and what the maximum
length of string / integer is.

Thanks for the ideas, our form is still a long way off being operational
so we have time to test and develop.

Regards and thanks for the wonderful application, this is really going to
speed up data collection and processing.

Regards,
Wesley

On Wednesday, September 19, 2012 9:27:02 PM UTC+2, Waylon Brunette wrote:

I should also add that currently you can launch an external android app
from collect but right now it can only accept one value back. The launch of
the external android app is mapped to a single question which in xforms
maps to a single value. Here are some links to previous threads on it.

http://groups.google.com/**group/opendatakit/browse_thread/thread/
88fc497a01c99e78/**cb15c9de739a554a?lnk=gst&q=launch+external+app#
cb15c9de739a554ahttp://groups.google.com/group/opendatakit/browse_thread/thread/88fc497a01c99e78/cb15c9de739a554a?lnk=gst&q=launch+external+app#cb15c9de739a554a

http://groups.google.com/**group/opendatakit/browse_thread/thread/
1e4555d0e969e3cd/**37d319b148a0f381?lnk=gst&q=*launching+external+app#
*37d319b148a0f381http://groups.google.com/group/opendatakit/browse_thread/thread/1e4555d0e969e3cd/37d319b148a0f381?lnk=gst&q=launching+external+app#37d319b148a0f381

As a quick hack you could have the 3 values returned as a string (need
to use string type) do some parsing on that string after the submission.
For example you could encode the string with a key value pairs. An example
could be 'small=12;medium=34;large=2'. You would then need to parse this
information once exported.

This is being fixed in the ODK 2.0 toolset where you can map a widget to
any number of values/questions in the form. However, with xforms and
javarosa they like one value per question and we have not figured out how
we would want to work around that. Examples like GPS and Multi-select still
have one answer value that requires special parsing similar to what is
suggested above.

Hope this was helpful explaining the constraints.

Waylon

On Wed, Sep 19, 2012 at 11:09 AM, Mitch S mitchellsundt@gmail.comwrote:

Several groups (corey@servalproject.org , prabhas.pokharel@gmail.com )have asked for 'group-of-data-values' submissions using custom external
apps to gather the data.

I don't have time to implement this, but I've referred everyone to this
plan: http://code.google.com/p/opendatakit/wiki/
XFormControlExtensionProposalhttp://code.google.com/p/opendatakit/wiki/XFormControlExtensionProposal

With this approach, you could write your own 'tap' app that had 3
buttons, and returned 3 data values into the form.

Perhaps the teams that need this could pool their resources and submit
a patch?

Mitch

On Wed, Sep 19, 2012 at 2:54 AM, Wes Roberts jwesroberts@gmail.comwrote:

Dear ODK community,

I am developing a survey for forest enumeration as part of a REDD
project. One of the key biomass parameters are shrubs. Our current
methodology simply records the shrub and places it into a size class based
on the height of the shrub (small: Below knee height, medium: knee to
shoulder, large: above shoulder). In practice a field plot technician walks
around the plot and calls out the sizes as he encounters the shrubs,
another field technician then records the number of shrubs per size group.
Currently, I have a "begin repeat" with a select_one inside giving the
technician the option to select either small medium or large. This should
work but presents a couple of issues.

  1. The begin repeat will create a separate table on aggregate which is
    problematic for automating data processing later on. I am sure this can be
    overcome with some javascripting online but would prefer the number of each
    shrub be recorded in the main table.

  2. Secondly, the "would you like to add another" option can be
    problematic in the field.

My question is thus, is there an option where I split the input screen
into three sections one for each size class. The technician will then have
the option of tapping a size class to record an occurrence. The table would
then contain three name variables (three size groups) with the number of
shrubs recorded in each.

Many thanks and looking forward to your responses,
Regards
Wes

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

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Dr Wesley Roberts
jwesroberts@gmail.com
Cell: 083 5355 646
Work: 021 - 888 2490
skype: roberts-w