Hi together,
I’m pretty sure this function is not available, but just to be absolutely sure:
Is it possible to limit the min/max map zoom levels (e.g. 9 - 13) or set a fixed zoom level in Enketo by setting these values in an XLS Form?
Best,
Daniel
Hello @DSimon,
As a workaround you might pre-set a GPS location value (by calculation or default) in the area where you want to zoom in.
1 Like
Thanks @wroos, we already do this to prevent unexpected zooming behavior when opening the map.
In this (and many other cases) we want participants to roughly mark their home location because we want to grant anonymity. Limiting the zoom level would then prevent them from setting the exact location, when they overlook the roughly in the question text.
But well, maybe that might be a feature for the future - if it’s technically possible at all.
Hello @DSimon,
great thst you csre for strong participant anonymity.
Additional ideas:
- You might let them take the real location (even with my location icon) and add a calculation to this variable (randomly) changing the GPS value by an offset.
- You might try with setting the accuracy to a low level parameters (ODK Collect).
- You might add a acknowledge question before or after the GPS question to remind on the “roughly”.
- You might separate GPS values after submission and store it (coded with case link/ID) in an extra and protected file, if needed for some spational analysis.
If your advice is “roughly”, no one will know if a submitted GPS is real or “roughly”. So, this is a protection already.
2 Likes
Hi @wroos,
thanks for the thoughts. The acknowledge question seems to be a good addition to the “roughly” instruction!
I also thought about your other suggestions but all of them will contain the original coordinates in the dataset, right? When taking GDPR seriously this would already force you to obtain an informed consent from the participant. This is what I would like to avoid and instead be able to state that a participation will be anonymously (we even disabled IP logging on our server - because it implies a very theoretical possibility of deanonymization). And combined with the “roughly” an approach that slightly modifies the location I would not expect an added value, since modification can then also be done afterwards (e.g. Donut masking).
That’s one GDPR downside: We have to wait for jurisdiction on when specific combinations of data points, especially when combined with location, are considered as anonymous or not. But this will always be context depended, e.g. asking for age, gender and location is completely different if a paricipant lives in a single family house or 30 story high rise.
I will definitely consider adding an acknowledge question. I only have some concerns regarding usability on mobile devices. Since you cannot integrate the acknowledge button in the map screen and will only see it after going back into the survey’s main screen. (We’re pretty much focused on good usability of our surveys.)
And yes, the advice of “roughly” marking should do exactly what you said. So far I’m going with this solution. But I have serious doubt, that this would would be recognized as sufficient by a court. So far noone sued us for violating GDPR terms. 
Thanks,
Daniel
1 Like
Hello @DSimon,
interesting discussion. Thanks.
The acknowledge type question could be required and directly comme before (or after) the GPS question. It could even appear on the same screen by using group with field-list appearance.
The GPS question with added calculation clause option would not keep the original GPS in the dataset. It would work on leaving the field (and on save).
Why do you need the GPS question? What do you do with it (when)? Perhaps there
might be another option, like village, quarter or street name?
You can also delete other protection sensible data elements before send (using a related question and relevant clause), e.g. names.
Hi @wroos,
The acknowledge type question could be required and directly comme before (or after) the GPS question. It could even appear on the same screen by using group with field-list appearance.
My concerns are on usability with mobile devices only, where the following scenario could be annoying: 1. Participant didn’t read the “roughly” and pins exact home location. 2. returns to main survey screen and gets prompted acknowledge question. 3. realizes the point position needs to be shifted. 4. opens map again, shifts position. 5. returns to main screen.
(We currently use something similar; but only to display a note saying that the location has been recorded, which will show up when ${geopoint} != 'DEFAULT_COORDS')
Why do you need the GPS question? What do you do with it (when)? Perhaps there
might be another option, like village, quarter or street name?
We do research on PPGIS usage in health promoting urban planning (I personally focus on inclusiveness of PPGIS methods for traditinally underrepresented and/or marginalized/deprived population groups). We mostly work in Germany. Since our work is embedded in interventional/preventional health projects (as urban planners), we of course focus on location. A classical survey setup (now only referring to location features) would consist of a repeat group, capturing several places participant visit or avoid (or exercise or whatever) and reasons for this. In the end, we then would ask for personal information, such as age, gender - and approx. home location. Afterwards we will be able to look at the spatial connections or analyse activity ranges/patterns.
Because these projects often focus on a cities’ district or even a specific settlement, higher level location data (like village or quarter) would not be sufficient. Street names can also be distorting when thinking of arterial roads that can cross whole districts of a city.
The GPS question with added calculation clause option would not keep the original GPS in the dataset. It would work on leaving the field (and on save).
You can also delete other protection sensible data elements before send (using a related question and relevant clause), e.g. names.
Oh, really? That’s very interesting! So, given an exact home location, it is possible to modify the original location via calculate and store a “masked” location (I can follow until here). And then erase the recorded data of the original/exact home location before sending? Or would the originally recorded exact home location be modified immedietly when recording the geopoint?
No matter which way round, that would be absolutely great! Could you kindly give me a hint to the functions to use to achieve this?
If this works as I imagine, some thought would need to go in the “algorithm” for the location modification that makes sure, that the modification factor is (1) randomly generated and (2) is within a specific range to control the min/max shifting radius.
Only if this is of importance: We only deploy via Enketo.
Thanks for you support!
1 Like
Guten Abend, @DSimon,
The idea was to put the “roughly” reminder just before the GPS question, as acknowledge type, required, constraint . = OK".
Both is possible.
a) If the calculation clause is added to the original GPS question, it would change the value. On leaving this field or on save or submission? I am not sure for Enketo, sorry. You may check it, please.
b) If you work with a question copy (might be a calculate type) and put the calculation there, the original GPS would not be changed.
The original GPS question could reference a (required?) question/acknowledge at the end of the questionnaire to activate deletion of the GPS original. A relevant clause at the original GPS question would reference this activation value.
Viele Grüße
Hallo @wroos,
in order to find out about modifying original values directly on input, I started very simple by applying a calculate clause to an integer question. It should just always output the entered number +1. This leads to very strange behavior and can only be used in preview mode (where it leads to absolutely strange results; e.g. when typing 1 the fields value changes to 264 or 276 or 288…; . Deploying results in an error message:
Unexpected KoBoCAT error 400: b’{“detail”:“ODK Validate Errors:\n>> Something broke the parser. See above for a hint.\nDependency cycles amongst the xpath expressions in relevant/calculate\n\nResult: Invalid”}’
Here’s my testing form:
| type | name | label | appearance | calculation |
|---|---|---|---|---|
| begin_group | g | field-list | ||
| integer | value1 | Number 1 | ${value1} + 1 | |
| note | show1 | Result 1: ${value1} | ||
| integer | value2 | Number 2 | ||
| calculate | calc | ${value2} + 1 | ||
| note | show2 | Result 2: ${calc} | ||
| end_group |
I also tried to use the calculation clause this way:
. + 1
But this does not modify the input value at all.
Here’s the form, if you want to test it.
SNIPPET_Location_Masking.xlsx (14.4 KB)
The second section, where ${value2} is handed over to a calculation and then displayed works as expected.
So this really puzzles me. Because so far I always thought referencing is only possible with values that come before the element that references them (except for using . to self reference a question, which does not seem to work here).
This is also relevent regarding your second suggestion, deleting values somewhere in the form triggered by an acknowledge at the very end.
I would be very glad if you could provide a concrete example, based on my testing form.
Danke für deine Hilfe!
1 Like
This may be a half-baked idea, but why don’t you use a geotrace (instead of a geopoint), and ask them to enter two points near their home, then average the two points to get the ‘rough’ location.
Not what the trace was intended for, but could work. You could also ask to draw a shape around their house and calculate the centroid, but that’s no longer trivial to calculate.
1 Like
This might also be a workaround. But I fear that this might be even more confusing to use for less tech savvy people. And participants could also draw a line only covering the building they live in.
Anyway, thanks for the suggestion.
