View source for SurveyCTO Dealing with 'Other' Crops Over Different Repeat Group Levels

#REDIRECT[[Repeat Groups and Rosters in SurveyCTO#Dealing With 'Other' Choices in a Repeat Group]]

Inside a self-contained repeat group, dealing with ''''other' choices''' is relatively straightforward - we can add an 'other' response to a [[SurveyCTO Dynamically Populated Choice Lists|dynamically populating choice list]] and select from there. However, this gets complicated under more complex structures.

== Read First ==
* Imagine that we are surveying smallholder farmers about their crop production and sales over the last year. To assist the [[Data Analysis | analysis]] and structure the interview, we should take into account the crops produced, which plots they were grown on, and in which season. This might require having 3 layers of repeat groups: season > plots > crops. 
* We are easily able to set up an ''''other' crop''' as an option for produced crops at the bottom level, however, once we want to refer to this 'other' crop at either the plot or season level or in a different repeat group, [[SurveyCTO Coding Practices | SurveyCTO]] cannot then link this selected ''''other' crop's ID''' with it's name if those ''''other'''' names are defined at the '''crop level'''.

== Best Practice == <onlyinclude>
There are several ways around this, though none are perfect:
# '''Ask enumerators''' to reserve an ''''other'''' crop option to a specific crop throughout the whole survey, where 'other crop 1' would always refer to one type, 'other crop 2' to another type and so on. In theory this would work, but is not recommended because of the large potential for enumerator error. 
# '''Keep all questions related to the crops''' contained within their respective repeat group at the lowest level. Again, this is not ideal for the form structure, as we don't always, for example, want to ask about a crop's sales or processing over plots or seasons - we may just want to ask at the crop level. 
# '''Define all the potential crops''' at the start (highest level) of the agriculture section. If we establish what the 'other' crops are at the start of the section, we can then dynamically add these to the crop choices in each lower level repeat group. The main drawback with this approach is that once the crops are defined you can't define more later on if the respondent forgets one. Out of the 3 approaches, this is the most viable to overcome the problem described above, especially when enumerators are well trained to predefine these 'other' crops and good form piloting has already defined all potential crops in the choice list. Also, any crops that the respondent may forget probably aren't that important anyway. The example below gives an example of how to develop a form under this approach.

== Coding Example ==
[https://drive.google.com/open?id=1SWRRv6_WxNdFmeColcw5jyRVhsbUmMP_HGfeSQa1uAc Here is a code example] of the issue in question. We have a survey where we want crop production data by plot in each season, so we set up a repeat group structure of ''season > plots > crops''. After this, we want sales data also. Let's say that a farmer combines all their production together after harvest, so that asking about crop sales per plot is confusing for them. In this case we would want to ask sales of each crop per season, so we'd need a new repeat group structure of ''season > crops''. If we just code 'other' crops at the plot level, when these are aggregated, SurveyCTO will not know which 'other' crop is being referred to or what it's name is. This approach overcomes this problem.

* After asking if they cultivated anything, we then ask what are the crops they cultivated over the past year. It's vital here that ALL 'other' crops are defined. Therefore if there are 3 crops missing from the list, 'Other crop 1', 'Other crop 2' and 'Other crop 3' must be selected and subsequently defined. The ''choice_filter'' column restricts the choices to being the undefined versions of the 'other' crops. 
* We then ask about the crops actually cultivated at the ''season > plot'' level. Even though we are referring to the same choices options, the list filters IN the defined 'other' crops and filters OUT the undefined options. Note the ''value'' and ''filter'' numbers for the crop choices. Only those that were selected in the first stage appear in the second stage. The ID and the name for the defined 'other' crops continue throughout the rest of the survey in this structure.
* To structure the questions at the  ''season > crops'' level, we first must aggregate all the crops that have been cultivated at the plot level. We do this through the expression <code>de-duplicate(' ', join(' ', ${crop1_id}))</code>, which first joins all the crop IDs at the plot level, then de-duplicates this list. We are left with a ''select_multiple'' type of number list, e.g. '''1 5 -81 7'''. In this case, '''-81''' would refer to the first of the defined 'other' crops.
* We can then pull the crops from this number list in the ''crop2'' repeat group, and pull the name from the choices from ''${crop}''. Note that the error would come at this stage if the other crops were defined inside of the ''crop1'' group, not at the most upper level.

== Related Pages ==
[[Special:WhatLinksHere/SurveyCTO_Dealing_with_%27Other%27_Crops_Over_Different_Repeat_Group_Levels&action|Click here for pages that link to this topic]].


[[Category: SurveyCTO Coding Practices ]]