Hello,
I wonder if it’s possible to link an answer to a question to a point on the map.
For example, to the ‘select’ question “where did the event happen?”, each of the cities listed as answers would have geopoint associated with them.
This way, even without a ‘point’ questions, data could be visualized on the map.
Thanks!
Raphael
You can technically populate the choice/item list of a select_one with any arbitrary string as the value. This is a bit unusual and not typically recommended, mainly because - for select_multiple - the various selected choices are stored in a string with a space delimiter; so if you happen to have an option whose value contains a space, it rather throws things off, breaks the selected() function, etc. But for a select_one this is less a concern.
Try running this simple form on XLSForm Online to see an working example [guess where I live… 
]:
selectgps.xls (25.5 KB)
Oh, and if you need to recover the original name of city selected, you can use the jr:choice-name() function.
Thank you @Xiphware that’s super helpful.
I’ve tried with the form you sent, but it is not showing anything on the map, just the regular answers on the data table. Am I missing something?
Also, would it be possible to get the ‘regular’ answers in the data table (London, New York, etc) and geopoints on the map?
PS: I’d guess you live in New Zealand? 
If you want to see the selected location on a map, you’d probably need to feed the selected gps location into a separate geopoint question and use it to pre-populate the widgets location. That’s not something I’ve tried, yet… (but check back tomorrow 
)
As to adding a custom label on the geopoint widget map with the city name, that’s beyond the scope of the defined geopoint control behavior. It may be possible in some implementations, but suffice to say it’s ‘non-standard’
As to adding a custom label on the geopoint widget map with the city name, that’s beyond the scope of the defined geopoint control behavior. It may be possible in some implementations, but suffice to say it’s ‘non-standard’
Sorry if I wasn’t clear, I wasn’t trying to add a custom label on the map. My objective is:
I’m not sure that’s possible.
geopoint question can take any input at the XForm level, but Collect only allows inputting coordinates either by accessing the GPS/network location sensor of the device or the user selecting a point on a map. Enketo has these features and also allows users entering coordinates manually.default question type only allows values, no dynamic lookups (so ${location} won’t work as a default value)geopoint question it encounters.Maybe @Xiphware has more creative ideas…
Challenge accepted! 
Actually, yes you can… 
In XForms any instance element binding can contain a calculation, including geopoints, although in the Kobo KPI form builder this ability is not exposed. But you can certainly have a geopoint result with a calculated value in an XML XForm (!), and with a bit of a fudge you can mimic the same in an XLSForm; see
selectgps.xls (19.5 KB)
In this XLSForm the geopoint has a calculation that picks up the gps string from your selected city. In order to prevent this being over-written I’ve had to make the question read_only, effectively disabling the map widget [aside, ideally you’d make this question relevant=false so the map doesn’t even get displayed, but as a side-effect (bug?) of some XForm clients, including Enketo, they dont bother running calculations of controls that are non-relevant. I must remember to talk to @martijnr about this…]. But the net result is you have a geopoint result in your form that is populated with the gps location of your selected city.
BTW, this is a lot cleaner to accomplish in an actual XML form, because there you can just specify the geopoint instance XML element and associated binding with the calculation, but no actual geopoint control. So the desired geopoint is in the final submission result but nothing is actually displayed in the Collect UI.
Again, whether or not your result viewer (eg Kobo map feature) shows the geopoint ${city} label or not on the map is beyond the scope of the XForm definition.
Holy smokes! That’s perfect, exactly what I was hoping for.
We’ll have to add support for calculate questions (currently not supported on our client, Tella), but once it’s done, it will definitely increase usability for some of our projects. Admins will be able to get both the name of the city in the data table, and the geopoint on the map.
Thank you 
Genius work, @Xiphware. calculates definitely work on non-calculate questions as well, and the result definitely shows the GPS coordinates on the KoBoToolbox map as desired.
I’m pasting the short form definition here for reference so people don’t have to download the XLS:
survey:
| type | name | label | calculation | read_only |
|---|---|---|---|---|
| select_one locations | location | select a city | ||
| calculate | city | jr:choice-name(${location},’${location}’) | ||
| geopoint | geopoint | ${city} | ${location} | true |
| note | show_geopoint | geopoint for ${city} is ${geopoint} |
choices:
| list_name | name | label |
|---|---|---|
| locations | 40.718396 -73.979032 0 0 | New York |
| locations | 51.567054 -0.062907 0 0 | London |
| locations | 48.868568 2.37855 0 0 | Paris |
| locations | -40.453722 175.841494 0 0 | Pahiatua |
YW 
Its not perfect; unfortunately you are still having to present users with a disabled map widget in the form. But unless you want to delve into the murky, wild, pirate-invested waters of raw XML forms, its probably about the best you can do within the safer confines of XLSForms
I think this is just a bug in Enketo. Widgets should update with calculated values when the value gets updated. geowidget not updating when calculated value updates · Issue #255 · enketo/enketo · GitHub
Sorry, I misunderstood that the issue was about creating a calculation with a geopoint datatype without a form control.
There is a super secret feature in XLSForm (don’t tell anyone). You can use the bind::type column to override the type of a question. In this case you’d want to use the value “geopoint” in that column.
P.S. The bug discovered is still valid and will be fixed eventually.
And as soon as @martijnr fixes the next bug we just found around this, I’ll re-post a form that does away with the map altogether! hehe
Thanks @Xiphware! Can be tracked here: https://github.com/enketo/enketo-core/issues/607
Fixed in version 1.75.3! Can be tested here: http://opendatakit.org/xlsform/
Thanks @martijnr for the quick fix.
Here’s an updated form that removes the map widget completely:
selectgps.xls (19.5 KB)
@raph, @tinok please have a go and make sure the new version still shows up in your Kobo map view. thnx.
Note, you might need to wait till Kobo updates its Enketo fork before trying to preview this new version in Kobo. If you try now you’ll get a “TypeError: this.question is null” error, which is bug 607 that was just fixed. But the above link to XLSForm Online will show how it ultimately looks.
