FYI I've created a pyxform github issue to track this new feature request: https://github.com/XLSForm/pyxform/issues/716
1 Like
The background-geopoint currently is unable to be nested within a repeat group like in permutation 3.
background_geopoint_trigger.xml (5.0 KB)
This is a known issue that has to do with 'incorrect' behavior (of Enketo) when it comes to resolving refs the underlying XForm action [the same issue results in regular trigger/setvalue actions misbehaving too].
For all the gory details see Incorrect (setvalue) trigger behavior in Enketo when used inside repeats.
There's a couple Enketo bugs/issues tracking this here:
1 Like
This was added to pyxform in 2.2.0 and is in Central v2024.3. Thanks, everyone!
1 Like
Where can I find details on implementing this? I checked the Central v2024.3 release announcement and search the docs, but am not finding anything. Apologies, I may be missing something obvious.
@danbjoseph Looks like we haven't had time to document it.
I'll see if we can get to that soon!
It's now documented in the user-facing docs: https://docs.getodk.org/form-question-types/#background-geopoint.
2 Likes
Perhaps also good to mentioned on the compatibility of this widget for collect and enketo. If I remember correctly, it doesn't work inside repeat also.
1 Like
An example might help here too - I tried to use it with Collect 2025.2.0 Beta 1 and Central v2024.3.2. The question background-geopoint appears on the form as an acknowledge question type with a checkbox, the value (showing it in a note) is null until I check it, then it's 'OK' when checked. When I change a question that is set as its trigger with or without the checkbox the value doesn't change to a location coordinate.
The uploaded values I saw were null if it's checked (triggered or not) and POINT ( ... ) if it's not checked but triggered.
I assume I'm missing something blindingly obvious here, but I shouldn't see the question label or be able to wipe the value with the checkbox if it's a background item?
Here is the example from the docs as a working form: https://docs.google.com/spreadsheets/d/1oPOszhovewBzjxYtHGif6VzrGOBE5N9EiXNPluWlwfg/
It should work with Enketo! I just verified that it works for me in Firefox. Keep in mind that location capture may not be immediate, especially the first time you fill out a form. When you change a question's value, you should either be prompted to give location permissions or see a location icon in the address bar. I find that I generally need to wait about 5 seconds before I submit to get a location reading.
This is also expected to work! And in a repeat is to me the most compelling context in which to use background-geopoint. I've used it to accurately map my neighbors during a walk around the block. Could you please share the form you're trying?
A quick example form would help troubleshoot, this sounds very surprising!
Please note the above known Enketo issue I mentioned earlier: https://github.com/enketo/enketo/issues/1347
It looks like the setvalue target XML element is not getting properly resolved when performed within a repeat group. So although the background-geopoint is being triggered and 'working' per se, its storing the result in the wrong place.
1 Like
tl;dr
I grabbed your example form and tested in 2025.2.0 Beta 2 (prev was beta 1), and it works exactly as expected... I also already deleted the test form from a couple weeks ago and didn't screenshot ;( ... I recreated a new form, two questions each triggering a different background-geopoint, in Enketo, the usual geopoint dialogue appears with an 'OK' at the bottom, and if you mouseover on it, a blue box appears and clicking fills the field with OK. Clicking in the map fills the lat/long but doesn't fill the field with location. If you hit the trigger it does fill the field with location, the map zooms to that location but the lat/long/etc fields stay blank. The form is invalid if the geopoint has been clicked and contains 'OK' but trashing it or retriggering it will allow submission. The note with the fields shows the location or 'OK'.
Click on map to fill lat/long, click in hitbox to fill background geopoint with OK
In Collect, I get the acknowledge appearance as mentioned earlier:
After triggering them, the ack is unchecked and the note with the fields doesn't display anything
I did have trouble getting a location fix, and no way to know it had succeeded until sending, as looking at the form TOC view didn't show the value, the note didn't show the value, but viewing the sent form did show the value in the field and note.
TOC view
Sent form view
It's not the field-list appearance in a group, I removed the group and it was the same.
Taking another look at your example.. you don't have a label on your background-geopoint and I do.
Removing the label hides the geopicker in Enketo and the check box in Collect, and shows the location in the note (Have to change screens to refresh it though) / TOC view. Here's a form with a wonky and a working one:
Background_Geopoint_label_issue.xlsx (576.7 KB)
Both Edge & Chrome defaulted to blocking location for me, the trigger question showed a location pin in the address bar, which could be clicked to change permission:
Once location allowed, Chrome attained location quickly, but Edge didn't succeed, up to 20s wait between trigger and submit and still nothing for me.
That makes sense, thanks! Sorry, I went back to thinking about Collect which is where I did extensive testing within repeats.
Oh no! That's definitely something we should guard against in pyxform. 
https://github.com/XLSForm/pyxform/issues/763
That feels like it could be a browser configuration issue. Maybe Edge's default is more privacy-preserving in some way? Enketo uses the standard browser location APIs so I don't think there's a lot we can do about this one.
I am referring to the context of trigger behavior inside repeat in Enketo, I am not quite sure whether the issue brought up by @Xiphware earlier has already been resolved.
I did click the barred location in the address bar to allow location, then a popup dialogue appeared and i allowed that, so i thought that would be enough. I'd have to go digging further into config options to try to resolve.
Always looking for new and interesting ways to break things 
1 Like
AFAIK this has not been fixed yet.
Presently the ref in a setvalue (aka trigger) or odk:setgeopoint (aka background-geopoint) action isnt being 'contextualized' correctly by Enketo for controls within a repeat group; instead it is always just referencing the XML element in the first iteration, not the current one.
Once this is fixed, both xforms-value-changed event triggers and background-geopoints should start to behave correctly in Enketo, as they do already in Collect.
You know, @ahblake, we did call it background-geopoint for a reason...
But I totally agree with @LN , good catch! I'd never have thought of doing that 
2 Likes
I'm just over here putting labels on everything
Does background-audio do similar funny things when a label is added? The examples in the docs do show no label but don't currently warn that one will cause an issue.
1 Like
I did a quick test as most everything else seems ok. Specifically, all the other 'hidden' metadata question types - start, end, etc - seem to happily ignore any superfluous label in the XLSForm.
However, as you observed, an unexpected label on a background-geopoint question seems to mysteriously turn it into a trigger question in Collect 
:
or turns it into an (ir)regular geopoint question under Enketo:
Both of which are quite incorrect client behavior.
almost - it's a hybrid geopoint-trigger! (see the 'OK' at the bottom, and click in the whitespace between the map and fields to activate the trigger)
2 Likes