The Entity-Based Data Collection Working Group was formed, met, came up with a high-level project plan, and is now seeking funding. Geo will eventually be central to what we have in mind but is currently looking like it will be layered on top of other upfront work. In the meantime, Ona has expressed renewed interest in what @Matt_Berg described above.
We propose adding a map appearance and geojson support to select_one_from_file. Initially the map appearance would only work with geojson files but we could expand it to work with all select_one variants (see extensions below). select_one_from_file with a geojson file and without the map appearance would provide a text interface identical to how select_one_from_file works today.
The user experience provided by the map appearance would be similar to a geopoint with the placement-map appearance. In the form, question text and a button with text “Select place” would be displayed. If a feature has previously been selected, its label (from the name property, see below) would be displayed.
When the “Select place” button is tapped, a map view would be launched. All features from the geojson file would be displayed on top of the basemap and any reference layer configured on the device. Instead of being able to select an arbitrary location, the user would be able to tap on any feature defined in the geojson file.
geojson files used with select_one_from_file:
-
MUST have a .geojson extension (not .json)
-
MUST define a single top-level
FeatureCollection
-
MUST define a property called
id for each feature in the collection (features without this property will be silently ignored; see extensions below for more flexibility which could be later introduced)
-
MAY define a property called
name for some or all features in the collection which will be used as the feature’s label (Note: I propose name because I’ve seen that in several geojson file examples. An alternative would be title which is specified by simplestyle. interested in opinions here!)
-
MAY define any number of additional custom properties for some or all features which will be displayed when a feature is selected (and eventually available to form logic, see extensions)
Points would be displayed as markers like the ones used for the filled form map . Additional feature types could be supported as described in the extensions below.
All of the features would be of the primary app color (blue-green) when unselected. The feature selected would be displayed in red to match the existing geo widgets. In the case of points, the marker would also increase in size (same as the filled form map).
When the quick appearance is specified in addition to the map appearance, tapping on a feature would select it immediately and the map screen would close.
When the quick appearance is not specified and a feature is tapped, a bottom sheet would be shown as on the filled form map. If the feature has a property called name, that property’s value will be shown as its label (above the horizontal rule). If there is no such property, the id/underlying value will be displayed as the label. Any properties in addition to id and name will be displayed in a table below the label.
When a feature is selected and the save icon is tapped, that feature’s id/underlying value would be saved as the question’s value, overwriting any previously-saved value (same as geotrace/shape). When the trashcan icon is tapped, the current selection is abandoned and any previously-saved value remains (same as geotrace/shape).
When a geojson file is used without the map appearance, the id property would be used as the underlying value/name and the name property would be used as the display value/label.
An additional requirement is the possibility to specify a feature not defined in the geojson file. For now, we propose pushing that to form design: the form definition could include label text that prompts data collectors to leave the question blank if the feature isn’t on the map. If the value is blank, a series of questions could be asked to define the new feature. Once we have the basic requirements in place, we’ll try this and see if it’s sufficiently clear.
Extensions:
- Add feature types
-
MultiPoint, LineString, MultiLineString as outlined circles with a white center separated by lines as for the geotrace widget
-
Polygon, MultiPolygon as outlined circles with a white center separated by lines as for the geoshape widget with the addition of a light shading of the enclosed area
- Any property defined in the geojson file could be accessed in expressions the same way that values from other datasets are. For example, if a field called
the_road has type select_one_from_file roads.geojson in an XLSForm, the repair_state property of the road selected could be accessed with expression instance('roads')/root/item[id=${the_road}]/repair_state. This would make it possible to do things like constrain the features that can be selected based on the current location or filter the features shown based on some condition (e.g. only show hospitals that have some specialized team)
- Add flexibility to the geojson requirements:
- if there is no property called
id, look for an id foreign member (sibling of type: https://datatracker.ietf.org/doc/html/rfc7946#section-6.1)
- allow specifying the property to use as the underlying value in the parameters column of the XLSForm (e.g.
name=the_id)
- allow specifying the property to use as the label in the parameters column of the XLSForm (e.g.
label=the_label)
- Support
map appearance on select_one. This would also require specifying either lat and lon columns or a geojson column from the parameters column of the XLSForm. (XForms spec might be weird; additional children for itemset? This is why we propose introducing the map appearance rather than only using the filename extension)
- Support
map appearance on select_multiple_from_file/select_multiple
- Allow styling using the simple style spec. This would make it possible for the geojson file to specify things like color for individual features.
