What we're thinking for XLSForm design is to borrow from the patterns established with selects and the upcoming addition to range to specify labels for range ticks.
We propose specifying the set of items to use as reference geometry in the parameters column as the value to the reference-geometry key. We're very open to name suggestions!
Values could either be:
a string interpreted as the name of a list (in-form choices, attached CSV or Entity List)
a ${} reference interpreted as a reference to a repeat (a list of repeat instances).
Each item in the resulting list MUST have a geometry value.
In either case, a filter expression could be specified in the choice_filter column to filter down the list. The naming feels a little bit awkward because the items used for reference geometry are not really choices but it feels easy enough to explain and worth reusing the same pattern as for selects.
For the plotgeoshape field on the survey sheet, the reference-geometry parameter is given the value plots. This references the plots CSV/Entity List shown above. The region=${selected_region} expression specified in the choice_filter column means that the only rows from plots that will be included are ones whose region property value matches the user-selected value in the selected_region form field.
For the transectgeotrace field on the survey sheet, the reference-geometry parameter is given the value ${transects}. This references a repeat in the form named transects. The repeat must contain at minimum a geometry field which will be used to map the repeat instances.
As we've currently specified things, you could choose to use the geometry captured in this session by referencing the repeat OR geometry captured previously by referencing the Entity List but not both. Displaying geometry from multiple sources (which this is a special case of) is out of scope for now but we may take it up at some point, possibly combined with specifying other sources of reference layers (e.g. URL). The XLSForm spec for this becomes tricky!
If any item doesn't have geometry will only that one not be shown or will none be shown? (for the case of incomplete datasets where <100% of items have geometry.)
I may have missed it, but can the list have a mix of point/line/shape geometries?
agree that given your time again perhaps choice_filter would be nodeset_filter, but I think it's easy to understand.
I think reference_geometry is clearer because it's tied to the geometry keyword we use everywhere else. If we want it shorter, ref_geo feels better to me, but in general, I prefer longer parameter names.
A first version of this functionality is now in beta! XLSForm support is not ready yet and we have decided not to do the dashed line for now. For now it only works in Google Maps.
Here's a demo XForm: ref_geo_demo.xml (3.3 KB) You don't need to open this or understand it -- if you upload it to Central it will let you create new Entities with geometry that will then be shown the next time you fill out the same form.
The first section of the form shows using an Entity List as reference for capturing new geometry. The second part shows using a repeat for the same.
Do you have an example places.csv to use to create the entity list? (edit: no matter, publishing it does the create step and all is well, I was trying to use the draft!))
This is a big step forward !
Of course we will suggest some improvements But that's so great ! First suggestion would be to keep the map extent/zoom the same between repeats.
Hi @LN, I tried the xml in ODK Collect but it seems not working. Maybe it is me(?). When I collect a feature, and then a second one, I don't see the first feature. Again, maybe it is me? By the way, what is the status now so far about using if in XLSforms and integrate it in our ODK collect forms. Thanks!
Hi @Edmonds and thanks for trying this out! I just gave it another try with our latest beta 3 and it works as I would expect.
There are two parts to the form: the first shows reference geometry from an Entity List and the second from a repeat. The first path requires finalizing or sending the submission and then the next time you open the form you should see that initial submission's geometry. The repeat geometry should be visible as soon as you start the next repeat instance. One thing to double check is that the places Entity List was created and is linked to the form.
If you're not seeing the expected behavior with the latest beta, please let me know what basemap you're using (you can see it in Settings > Maps) and what you're seeing happen. You can also share a screen recording.
We're a day or two away from merging pyxform support, I'll update again when it's available to try. It will be released in Central hopefully within the next 10 days or so and the the Collect release is projected for the second week of July.
I tried again. I have an entity list 'places', but the submitted polygon is not appearing when it is uploaded and synced with the entity list again. This entity list is however only necessary for the first path, right? For the repeat geometry, this list should not be needed, correct? Still, also when I am using the repeat, the previous collected line of the first repeat is not showing up in the second repeat. I am using the Google source as basemap with the map style 'streets'.
The issue should be at my side then. I am using ODK Collect v2026.2.2.
I think this only works on 2026.3.0 Beta... Is that the cause of the issue? You'd need to set up a separate Google Account and join the Beta programme at this stage.
Apologies for the late entry to this one - Finally got a beta account working again (and 5 minutes to test!)
. Geometry:
This is excellent for capturing data in the field - being able to see previously captured lines and polygons. The function works well especially with both repeats and entities. Looks like I might need to review my forms to use repeats again!
To confirm something raised earlier in the thread, when I add a point to the entity list, what with entities being geometry agnostic, the next time I open the form, hey presto, the point appears as well as the polygon... So guess we could collate a 'layer' of entities that would show different geometry types on the same map. Now that's really useful!
Can we do that with repeats? e.g. use a geopoint question and/or a trace within a repeat (might be a relevant question thing for differentiating). I know I'm getting ahead of myself but if I used a calculate row that collates the geometry within a repeat.(let's call it reference_geometry for the sake of confusing things)
parameters could then be reference_geometry=${reference_geometry} - is that possible?
I'm using this technique already when creating entities that have different geometry types (the calculate field is my save_to geometry). Then when I import to QGIS my plugin (QuODK) looks for the keyword geometry and translates into layers accordingly... So this would be a consistent 'extension'
@mathieubossaert idea of consistent zoom sounds interesting, but if Collect does the usual thing of zooming to your GPS location, that should be OK (always more difficult to test these things in the office).
Keyboard:
Excellent - much less intrusive to remain 'flicker-free'
Yes, my apologies @Edmonds, we're still in beta and gathering feedback before release mid-July! You can find more information about the beta here.
That's right, the special geometry Entities column or form field can contain a mix of any of the geo types in ODK format.
Yes, same thing. Currently the functionality requires having a field named geometry in your repeat. You could coalesce values from different sources into that field and they could have a mix of geo types.
Sounds like you have some great ideas on how to leverage this, hurray!
Perfect, even easier than I thought - that's what I am doing already and the soon to be updated QuODK also picks that up. I have been anticipating the Central map function that, I think, looks for the first geometry field, so I'm starting to collate things in my forms to handle that...
That gives a strong sense of consistency rather than just being a trick that you need to know... which means I can perhaps foreground it in QuODK.
Without trying to put a spanner (wrench) in the works... After testing this, I was reminded of this issue / idea:
My issue is where we are mapping contiguous 'sections' and being able to tell that it is not just a single line... (example in the forum post) This could occur here - all existing geometry (from repeats at least) shows as the same blue colour. I have a workaround when importing existing geometry as entities (a different stroke-color value based on odd-even number to give a segmented pattern), but I wonder how to deal with this on a device (creating new entities or within repeats) - could it be done the same way with a calculate field in the form definition (picking up on the repeat number being odd/even and applying a stroke-color value) and would Collect be able to pick that up when rendering?
Maybe something to think about later, and might be 'niche' enough to not worry about.
Yes it can! You can use any of the style field names in the repeat used as reference geometry and they will be honored as they would be in an Entity List, geojson file, etc.
XLSForm support is now available on https://getodk.org/xlsform/ if you'd like to give it a try. You can upload an XLSForm, download the converted XForm, and then upload it to your Central instance.
Please note that we changed the parameter name to reference-geometry with a dash rather than an underscore to match other parameters for geo questions.
Presumably in a repeat we need to add a question called stroke (and marker-color if a point), and for an entity it will have properties named the same?
So, on-the-fly, we could keep a count of repeats and use if(${repeat_count} % 2 = 1, '#111111', '#222222') in the calculation so that adjacent line starts / ends are alternating colours (and choose better colours!). Or colour coding according to other answers - having an extra column in the choices that would populate that field, for example?
I have a form that would benefit from that, immediately, without too much interference to existing form design.
But that's so great !
and the soon to be updated QuODK also picks that up. I have been anticipating the Central map function that, I think, looks for the first geometry field, so I'm starting to collate things in my forms to handle that...