Display existing geometry when capturing new point/trace/shape on map

[LN]

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_geo 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 example:

survey sheet

type	name	parameters	choice_filter
geoshape	plot	reference_geo=plots	region=${selected_region}
geotrace	transect	reference_geo=${transects}

plots CSV/Entity List

name	label	geometry	region
XH875f	Jenny's farm	-117.2 32.7 18.4 4.3 2.1;-117.2 32.7 19.1 3.8 2.6;-117.2 32.7 17.8 5.2 1.9;-117.2 32.7 20.0 4.9 2.4;-117.2 32.7 18.9 3.6 2.2;-117.2 32.7 18.4 4.7 2.0	a
JK03xf	Sadiq's homestead	32.6 -25.9 12.3 3.9 1.8;32.6 -25.9 13.1 4.4 2.2;32.6 -25.9 11.7 3.5 1.6;32.6 -25.9 12.9 4.8 2.5;32.6 -25.9 12.5 3.7 2.0;32.6 -25.9 12.3 4.1 1.9	b

For the plot geoshape field on the survey sheet, the reference_geo 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 transect geotrace field on the survey sheet, the reference_geo 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.

@ahblake

can >1 dataset be shown, eg polygons with farmers fields and points with plant locations.

@ahblake

If the reference geometry is from an entity list, and the collection is save_to-ing that entity list, in a repeat, will previous repeat geometries be added to the layer of existing geometries? (Assume a new submission will use the updated entity list so the prior submission values would be shown. Mid form I'm not sure...)

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!

@Edmonds

So a filter on device level (user level?) that reduces the number of sites downloaded from the entity list would be ideal. As far as I know, entity list are always pushed entirely to all devices and filters are arranged in the ODK forms.

This is something scheduled for the next release of Central and that we are finalizing the details for. Here's our current plan: Limiting Entity access for App Users and Data Collectors - #18 by norlowski

@dast

Please consider adding a feature to the XLS form that allows to specify at form level the time interval at which individual points are recorded in automatic mode. Depending on requirements, this interval may need to be shorter (for very small polygons) or longer (for large polygons).

We hear you! Here's a thread for that: Geotrace and geoshape in Collect: specify input method in form design

[ahblake]

@LN

Each item in the resulting list MUST have a geometry value.

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?

@LN

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.

agree that given your time again perhaps choice_filter would be nodeset_filter, but I think it's easy to understand.

[LN]

@ahblake

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.)

Invalid items will be skipped, others will be shown!

@ahblake

but can the list have a mix of point/line/shape geometries

Yes, no problem.

[yanokwa]

@LN

We propose specifying the set of items to use as reference geometry in the parameters column as the value to the reference_geo key. We're very open to name suggestions!

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.