Simplified examples are easier to fix, and then you can work on building
them out.
I've changed your choices sheet to have a column heading of
'feature_cat_filter' so that it is clearer what is going on.
Attached is a working implementation.
When you are working inside repeat groups, things get tricky.
In your example, you don't need to use indexed-repeat() because you are
referencing a value within your current repeat group. So you can use
relative addressing, e.g.,
../../g3/feature_cat
from within the feature_type field (instead of ${feature_cat})
../ gets up to the g4 group
../../ gets up to the parent of the g4 group (r1)
../../g3 navigates into the g3 group
../../g3/feature_cat references the value of the feature_cat field for
this iteration of the group.
i.e., relative addressing is a central concept to use and understand when
working within repeat groups.
HOWEVER, there is a gotcha in the evaluation logic whereby the filter
criteria is evaluating one level up (starting at g4 instead of at
'feature_type'). I believe this is a bug, but it has been out there so
long, we can't really fix it. So when we reference the feature_cat within
the filter criteria, we need to drop a leading ../ (using
../g3/feature_cat).
This is different than if you had tried to use relative referencing
within relevant, calculate or constraint conditions. In those, you would
need to write ../../g3/feature_cat
BUT, it still doesn't work.
The filter condition translates into the XML representation:
<itemset
nodeset="instance('feature_type_list')/root/item[feature_cat_filter
=../g3/feature_cat]">
And that is incorrect XML. The filter condition:
[feature_cat_filter =../g3/feature_cat]
evaluates all relative (..) addressing relative to:
instance('feature_type_ist')/root/item
i.e., ../g3/feature_cat is evaluated within the choices list, and not
within the form submission we are capturing. The solultion is to add
current()/ in front to reference to evaluate it within the current form
submission. That gives:
<itemset
nodeset="instance('feature_type_list')/root/item[feature_cat_filter
=current()/../g3/feature_cat]">
which works.
Again, the corrected form is attached.
Enjoy!
Slimmed.xlsx (16.2 KB)
···
On Mon, Apr 6, 2015 at 4:59 PM, wrote:
Also note that this one hasn't even been altered to allow shared choices
for different answers. If I use this form in ODK collect, the option to
select any choice disappears.
--
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/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com