Trick to storing default values?

Support
1

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need to
be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles this
type of information? Perhaps a loop of some sort or a way to enter and
store temporary default values that are then applied to following data
records?

Many thanks!
Adam

2

One way is to generate a set of barcode stickers, one for each field
excursion.

Create a 'field excursion' form that scans the barcode and captures the
metadata for that field excursion.

Then, on your observation form, scan that same barcode, and collect your
observations.

Keeps it simple, allows you to link the two data sets, at the cost of
having to figure out how to manage the distribution of the barcode
stickers, and figuring out how to effectively integrate their use into your
processes.

Mitch

··· On Fri, Nov 1, 2013 at 8:37 AM, Adam Kozlowski wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need to
be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles this
type of information? Perhaps a loop of some sort or a way to enter and
store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

3

Adam,

Another idea is that you can link data on the back-end, using a combination
of the deviceid and the starttime (both of which are fields you can
auto-record as part of your form). Thus, you can have them fill out one
form, then fill out one or more others, and you can connect the data later,
on the back-end. In some of our surveys, we've done that for capturing the
location, interviewer, etc. -- stuff we don't want to ask over and over for
every survey.

Best,

Chris

··· On Fri, Nov 1, 2013 at 11:37 AM, Adam Kozlowski wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need to
be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles this
type of information? Perhaps a loop of some sort or a way to enter and
store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

Thanks for the fast response Mitch.

Use of an ID field to link survey level data (weather, observers, route) of

one form to the observation data (species, sex, age, location) collected by
another form is a good idea - essentially what is done by a true relational
database. Although since fields like weather (wind, cloud cover,
temperature) are determined right at the beginning of a survey, barcodes
might be burdensome - print them out right there in the truck before moving
on to collect observation data? Might be a better solution for the first
form to generate a survey code and then have the user manually enter it at
the top of each successive observation record to link it to those starting
conditions. Still seems pretty clunky though.

There is no way to store (cache) a value from Form 1 to later harvest for
use in Form 2?

Cheers,
Adam

5

Thanks Chris - working with the data on the back end seems like the best
solution for now. But with multiple surveys an evening per device, it will
take some post-processing time to link all the observation records (all
with the same date) to the survey event. Logic something along the lines
of: link observation to survey with closest start time less than
observation time.

In my assessment, the inability of ODK to smoothly handle one-to-many data
limits it's strength to situations where data are collected in a one
event-per site scenario (this stems from the limitations of storing data as
a flat file not a relational database). There are of course many, many
situations where this is exactly the case (e.g. home visits, clinic
visits, culverts, building inspections, etc.) but FYI for others out there
with similar data collection needs as mine... Cybertracker (free,
http://cybertracker.org/) has an interesting way of dealing with this (now
with Android version).

Although CyberTracker stores data as a flat file also, it allows you to
store default values (data fields that hold their value from record to
record until changed). So you can fill out the event/survey level data
once - and all records completed after that will be stamped/appended with
those data. It is a simple but effective way to not have to ask a survey
user to repeatedly enter data. The resulting flat file is not normalized
data (flat files frequently aren't), but it does come out as all one piece

  • no linking necessary - and can be pulled directly into a relational
    database for processing.

Cheers,
Adam

··· On Fri, Nov 1, 2013 at 2:37 PM, Christopher Robert wrote:

Adam,

Another idea is that you can link data on the back-end, using a
combination of the deviceid and the starttime (both of which are fields you
can auto-record as part of your form). Thus, you can have them fill out one
form, then fill out one or more others, and you can connect the data later,
on the back-end. In some of our surveys, we've done that for capturing the
location, interviewer, etc. -- stuff we don't want to ask over and over for
every survey.

Best,

Chris

On Fri, Nov 1, 2013 at 11:37 AM, Adam Kozlowski <adamkozlowski45@gmail.com wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need to
be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles this
type of information? Perhaps a loop of some sort or a way to enter and
store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

6

And "the inability of ODK to smoothly handle one-to-many data limits it's
strength" is exactly why we are working on the ODK 2.0 tools -- Tables and
Survey.

Mitch

··· On Mon, Nov 4, 2013 at 6:46 AM, Adam Kozlowski wrote:

Thanks Chris - working with the data on the back end seems like the best
solution for now. But with multiple surveys an evening per device, it will
take some post-processing time to link all the observation records (all
with the same date) to the survey event. Logic something along the lines
of: link observation to survey with closest start time less than
observation time.

In my assessment, the inability of ODK to smoothly handle one-to-many data
limits it's strength to situations where data are collected in a one
event-per site scenario (this stems from the limitations of storing data as
a flat file not a relational database). There are of course many, many
situations where this is exactly the case (e.g. home visits, clinic
visits, culverts, building inspections, etc.) but FYI for others out there
with similar data collection needs as mine... Cybertracker (free,
http://cybertracker.org/) has an interesting way of dealing with this
(now with Android version).

Although CyberTracker stores data as a flat file also, it allows you to
store default values (data fields that hold their value from record to
record until changed). So you can fill out the event/survey level data
once - and all records completed after that will be stamped/appended with
those data. It is a simple but effective way to not have to ask a survey
user to repeatedly enter data. The resulting flat file is not normalized
data (flat files frequently aren't), but it does come out as all one piece

  • no linking necessary - and can be pulled directly into a relational
    database for processing.

Cheers,
Adam

On Fri, Nov 1, 2013 at 2:37 PM, Christopher Robert crobert@surveycto.comwrote:

Adam,

Another idea is that you can link data on the back-end, using a
combination of the deviceid and the starttime (both of which are fields you
can auto-record as part of your form). Thus, you can have them fill out one
form, then fill out one or more others, and you can connect the data later,
on the back-end. In some of our surveys, we've done that for capturing the
location, interviewer, etc. -- stuff we don't want to ask over and over for
every survey.

Best,

Chris

On Fri, Nov 1, 2013 at 11:37 AM, Adam Kozlowski < adamkozlowski45@gmail.com> wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need
to be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles this
type of information? Perhaps a loop of some sort or a way to enter and
store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

7

Fantastic! I am very much looking forward to it. Thanks Mitch.

-Adam

··· On Mon, Nov 4, 2013 at 1:01 PM, Mitch Sundt wrote:

And "the inability of ODK to smoothly handle one-to-many data limits it's
strength" is exactly why we are working on the ODK 2.0 tools -- Tables and
Survey.

Mitch

On Mon, Nov 4, 2013 at 6:46 AM, Adam Kozlowski adamkozlowski45@gmail.comwrote:

Thanks Chris - working with the data on the back end seems like the best
solution for now. But with multiple surveys an evening per device, it will
take some post-processing time to link all the observation records (all
with the same date) to the survey event. Logic something along the lines
of: link observation to survey with closest start time less than
observation time.

In my assessment, the inability of ODK to smoothly handle one-to-many
data limits it's strength to situations where data are collected in a one
event-per site scenario (this stems from the limitations of storing data as
a flat file not a relational database). There are of course many, many
situations where this is exactly the case (e.g. home visits, clinic
visits, culverts, building inspections, etc.) but FYI for others out there
with similar data collection needs as mine... Cybertracker (free,
http://cybertracker.org/) has an interesting way of dealing with this
(now with Android version).

Although CyberTracker stores data as a flat file also, it allows you to
store default values (data fields that hold their value from record to
record until changed). So you can fill out the event/survey level data
once - and all records completed after that will be stamped/appended with
those data. It is a simple but effective way to not have to ask a survey
user to repeatedly enter data. The resulting flat file is not normalized
data (flat files frequently aren't), but it does come out as all one piece

  • no linking necessary - and can be pulled directly into a relational
    database for processing.

Cheers,
Adam

On Fri, Nov 1, 2013 at 2:37 PM, Christopher Robert <crobert@surveycto.com wrote:

Adam,

Another idea is that you can link data on the back-end, using a
combination of the deviceid and the starttime (both of which are fields you
can auto-record as part of your form). Thus, you can have them fill out one
form, then fill out one or more others, and you can connect the data later,
on the back-end. In some of our surveys, we've done that for capturing the
location, interviewer, etc. -- stuff we don't want to ask over and over for
every survey.

Best,

Chris

On Fri, Nov 1, 2013 at 11:37 AM, Adam Kozlowski < adamkozlowski45@gmail.com> wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline data
collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need
to be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles
this type of information? Perhaps a loop of some sort or a way to enter
and store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

8

Hi Adam,

I'm a bit confused. Why can't you use sub forms within a single survey?

Regards

Neil

··· On 06/11/2013 12:10 AM, "Adam Kozlowski" wrote:

Fantastic! I am very much looking forward to it. Thanks Mitch.

-Adam

On Mon, Nov 4, 2013 at 1:01 PM, Mitch Sundt mitchellsundt@gmail.comwrote:

And "the inability of ODK to smoothly handle one-to-many data limits it's
strength" is exactly why we are working on the ODK 2.0 tools -- Tables and
Survey.

Mitch

On Mon, Nov 4, 2013 at 6:46 AM, Adam Kozlowski <adamkozlowski45@gmail.com wrote:

Thanks Chris - working with the data on the back end seems like the best
solution for now. But with multiple surveys an evening per device, it will
take some post-processing time to link all the observation records (all
with the same date) to the survey event. Logic something along the lines
of: link observation to survey with closest start time less than
observation time.

In my assessment, the inability of ODK to smoothly handle one-to-many
data limits it's strength to situations where data are collected in a one
event-per site scenario (this stems from the limitations of storing data as
a flat file not a relational database). There are of course many, many
situations where this is exactly the case (e.g. home visits, clinic
visits, culverts, building inspections, etc.) but FYI for others out there
with similar data collection needs as mine... Cybertracker (free,
http://cybertracker.org/) has an interesting way of dealing with this
(now with Android version).

Although CyberTracker stores data as a flat file also, it allows you to
store default values (data fields that hold their value from record to
record until changed). So you can fill out the event/survey level data
once - and all records completed after that will be stamped/appended with
those data. It is a simple but effective way to not have to ask a survey
user to repeatedly enter data. The resulting flat file is not normalized
data (flat files frequently aren't), but it does come out as all one piece

  • no linking necessary - and can be pulled directly into a relational
    database for processing.

Cheers,
Adam

On Fri, Nov 1, 2013 at 2:37 PM, Christopher Robert < crobert@surveycto.com> wrote:

Adam,

Another idea is that you can link data on the back-end, using a
combination of the deviceid and the starttime (both of which are fields you
can auto-record as part of your form). Thus, you can have them fill out one
form, then fill out one or more others, and you can connect the data later,
on the back-end. In some of our surveys, we've done that for capturing the
location, interviewer, etc. -- stuff we don't want to ask over and over for
every survey.

Best,

Chris

On Fri, Nov 1, 2013 at 11:37 AM, Adam Kozlowski < adamkozlowski45@gmail.com> wrote:

Hello all -

New to ODK. Would like to use XLSforms to build forms for offline
data collection for biological surveys (water quality, bathymetric mapping,
invasive weeds, deer surveys, etc.). I am used to working with relational
databases (one-to-many) so am wrestling with how to design flat forms
(one-to-one) using ODK that don't require the user to have to re-enter the
same info over and over.

For example, before a deer survey starts, survey conditions first need
to be reported (observer names, vehicle type, route, weather parameters,
etc.). These values act as metadata for the survey event and apply to all
the individual data records collected during that survey event. Ideally
the user would enter this survey level data (weather, name, etc.) once and
then proceed to enter data about each deer encountered on that survey.

Anyone have any advice or a sample form they can share that handles
this type of information? Perhaps a loop of some sort or a way to enter
and store temporary default values that are then applied to following data
records?

Many thanks!
Adam

--

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

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

9

Hi Neil -

Hmm, perhaps I can use subforms. Could you tell me more about them? I was unable to find a clear description on how they are working after a quick search.

Do they function so that a user fills out the parent form, comes to the child (sub)form and then can complete the child form multiple times saving a distinct record after each completion? On the backend it would appear that for each row, the parent fields would be the same (representing survey level data, e.g. site, date, surveyor, methods, etc.), while each child field would contain a new value as you moved row to row representing a different observation (age, sex, coordinate, bearing, distance, etc.) made on that survey?

Is there an example of a XForm using subforms you could post? AS you can probably guess downloading forms and opening them blindly on FormHub hoping for one with a subform has not been fruitful.

Thanks!
Adam

··· On Tuesday, November 5, 2013 6:00:24 PM UTC-5, Neil Penman wrote: > Hi Adam, > > I'm a bit confused. Why can't you use sub forms within a single survey? > > Regards > > Neil
10

Hi Adam,

By sub forms I just mean repeating groups. All questions within the
"begin repeat", "end repeat". I'm not sure about aggregate or Survey CTO,
and I'm sure there are other servers you could use, but the Smap Server
which is compatible with odkCollect stores uploaded data in a relational
database one table per form / sub-form.

The following link shows how you can use the relational setup when
exporting to spreadsheets.
http://blog.smap.com.au/features/export-reports-to-spreadsheet/. The survey
I reference on that web page is at
https://smap-suite.googlecode.com/files/multi%20repeat.xls

It does sound like ODK Tables 2.0 will help you a lot with completing
large, long running surveys, on your phones but hopefully this helps with
your requirements specifically around handling one to many relationships at
the server side at least.

I have added some comments inline to your email text.

regards

Neil

Hi Neil -

Hmm, perhaps I can use subforms. Could you tell me more about them? I
was unable to find a clear description on how they are working after a
quick search.

Do they function so that a user fills out the parent form, comes to the
child (sub)form and then can complete the child form multiple times saving
a distinct record after each completion?

Yes. If you put your subform / "begin repeat" at the end of your main
form's questions. The sub forms records are part of a single XML results
file on the phone. However on the Smap Server they are stored in their own
relational table which has a parent child relationship to the table storing
the main forms data.

On the backend it would appear that for each row, the parent fields would

be the same (representing survey level data, e.g. site, date, surveyor,
methods, etc.), while each child field would contain a new value as you
moved row to row representing a different observation (age, sex,
coordinate, bearing, distance, etc.) made on that survey?

Yes. as per the web page previously referenced

Is there an example of a XForm using subforms you could post? AS you can
probably guess downloading forms and opening them blindly on FormHub hoping
for one with a subform has not been fruitful.

Link provided.

··· On Thu, Nov 7, 2013 at 12:36 AM, wrote:

Thanks!
Adam

On Tuesday, November 5, 2013 6:00:24 PM UTC-5, Neil Penman wrote:

Hi Adam,

I'm a bit confused. Why can't you use sub forms within a single survey?

Regards

Neil

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Smap Consulting http://smap.com.au/| Mobile Data Collection Solutions
Application Developer - neilpenman@gmail.com minqiang.huang@gmail.com
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog: http://blog.smap.com.au http://smap.com.au/blog

11

Many thanks Neil for the advice/clarification and excellent example
spreadsheet! I now have a much better feel of the context of your
suggestions and will surge ahead adapting them to my needs. Thanks for
taking the time to help a ODK newby out.

Much obliged,
Adam

··· On Wed, Nov 6, 2013 at 4:39 PM, Neil Penman wrote:

Hi Adam,

By sub forms I just mean repeating groups. All questions within the
"begin repeat", "end repeat". I'm not sure about aggregate or Survey CTO,
and I'm sure there are other servers you could use, but the Smap Server
which is compatible with odkCollect stores uploaded data in a relational
database one table per form / sub-form.

The following link shows how you can use the relational setup when
exporting to spreadsheets.
http://blog.smap.com.au/features/export-reports-to-spreadsheet/. The
survey I reference on that web page is at
https://smap-suite.googlecode.com/files/multi%20repeat.xls

It does sound like ODK Tables 2.0 will help you a lot with completing
large, long running surveys, on your phones but hopefully this helps with
your requirements specifically around handling one to many relationships at
the server side at least.

I have added some comments inline to your email text.

regards

Neil

On Thu, Nov 7, 2013 at 12:36 AM, netn.im.nps@gmail.com wrote:

Hi Neil -

Hmm, perhaps I can use subforms. Could you tell me more about them? I
was unable to find a clear description on how they are working after a
quick search.

Do they function so that a user fills out the parent form, comes to the
child (sub)form and then can complete the child form multiple times saving
a distinct record after each completion?

Yes. If you put your subform / "begin repeat" at the end of your main
form's questions. The sub forms records are part of a single XML results
file on the phone. However on the Smap Server they are stored in their own
relational table which has a parent child relationship to the table storing
the main forms data.

On the backend it would appear that for each row, the parent fields would

be the same (representing survey level data, e.g. site, date, surveyor,
methods, etc.), while each child field would contain a new value as you
moved row to row representing a different observation (age, sex,
coordinate, bearing, distance, etc.) made on that survey?

Yes. as per the web page previously referenced
http://blog.smap.com.au/features/export-reports-to-spreadsheet/

Is there an example of a XForm using subforms you could post? AS you can
probably guess downloading forms and opening them blindly on FormHub hoping
for one with a subform has not been fruitful.

Link provided.

Thanks!
Adam

On Tuesday, November 5, 2013 6:00:24 PM UTC-5, Neil Penman wrote:

Hi Adam,

I'm a bit confused. Why can't you use sub forms within a single survey?

Regards

Neil

--

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

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Smap Consulting http://smap.com.au/| Mobile Data Collection Solutions
Application Developer - neilpenman@gmail.com minqiang.huang@gmail.com
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog: http://blog.smap.com.au http://smap.com.au/blog

--

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

You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/BdHh8mwEa6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.