Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geo vector feature selection field type? #1348

Open
edrex opened this issue Oct 30, 2014 · 3 comments
Open

Geo vector feature selection field type? #1348

edrex opened this issue Oct 30, 2014 · 3 comments

Comments

@edrex
Copy link

edrex commented Oct 30, 2014

Our surveys have a question type we call "planning unit". The way it works is that we create a GeoJSON FeatureCollection[1] where each feature is a grid rectangle (but they could really be any shape), and then the respondent selects a particular unit (or group of units for a multivalued question type) by pointing to the feature on the map[2].

We would like to explore the effort needed to extend Formhub and Enketo to support this question type (actually 2, a single and multiple selection version). I'm interested in doing this right, in such a way that it can be adopted out later, but I'm also very new to the ecosystem so don't have a good idea of whether an implementation would require changing more than just Formhub and enketo-legacy code. Reading through the ODK Developers thread discussing geotrace and geoshape for background.

Guidance?

Sketch of an implementation spec:

  • Field types geofeatureselect and geofeatureselectgroup (unless there's a way to make the UI nice by special-casing the handling of the repeat tag to just show a single map widget using appearance).
  • Add GeoJSON file containing features as a Media File (Supplementary Files must be CSV, yes?) and reference in field definition calculate field similar to [pulldata](http://xlsform.org/#pre-loading csv data), something like pullfeatures('my_features.json').

Any major issues with this sketch? Suggestions to improve?

[1] Such as with geojson.io
[2] Our current implementation uses Open Layers 2

@MartijnR
Copy link

Cool stuff. Not sure if this requires any changes on the formhub side. On the enketo side:

  • see implementation of geoshape and geotrace. This is supported in Formhub's Enketo installation too, but formhub needs to update pyxform to start using the new datatypes.
  • enketo-express will support external data but it will be different from the 2 ODK implementations. No plans to implement this in enketo-legacy (but most of the work is in enketo-core which is used by both enketo-legacy and enketo-express).
  • I guess you have 2 options for datatypes and appearances:
  1. use geoshape, and add new datatype multigeoshape or something with a new appearance (note: adding datatypes is a big undertaking as it requires changes in ODK Validate (and Collect) as well) .
  2. use the select and select1 datatypes with a new appearance. In this case, most of the implementation could be done by adding a new widget to enketo-core.

@edrex
Copy link
Author

edrex commented Oct 30, 2014

Thanks for the guidance, this is enormously helpful.

  • enketo-express will support external data but it will be different
    from the 2 ODK implementations.
    No plans to implement this in enketo-legacy (but most of the work is in
    enketo-core which is used by both enketo-legacy and enketo-express).

Assuming the initial implementation targets enketo-legacy, would it be
feasible to use the media upload support in Formhub to store a GeoJSON
feature file? My understanding is that media files are included in the
application cache manifest (but will be stored in IndexedDB in
enketo-express).

I guess you have 2 options for datatypes and appearances:

  • use geoshape, and add new datatype multigeoshape or something with a
    new appearance (note: adding datatypes is a big undertaking as it requires
    changes in ODK Validate (and Collect) as well) .

In our current implementation we just capture the ID(s) of the selected
Feature(s), which are in the Feature properties (example)
rather than storing the actual geometry, so it seems like we could just use
one of the existing datatypes.

  • use the select and select1 datatypes with a new appearance. In this
    case, most of the implementation could be done by adding a new widget to
    enketo-core.

This seems like a pretty expedient approach, thanks so much for suggesting
it!
I wonder if it would be straightforward (and not require changes on the
Formhub side) to load select values from an uploaded GeoJSON file rather
than CSV. This isn't a hard requirement, but would make creating/working
with geometry nicer. Does Formhub server-side validate selected values
against the CSV file? If so, it seems like changes would be needed on the
server to support loading values from GeoJSON.

@MartijnR
Copy link

Assuming the initial implementation targets enketo-legacy, would it be
feasible to use the media upload support in Formhub to store a GeoJSON
feature file? My understanding is that media files are included in the
application cache manifest (but will be stored in IndexedDB in
enketo-express).

Yes, but currently this file won't be automatically added to the ApplicationCache. Actually, if feasible, I would consider adding the geo shapes to the XForm itself (not as external data).

I also wonder if it makes sense to use the existing geoshape format instead of GeoJSON. It make the widget simpler as you could use the current geowidget as a basis (as this will already be able to display geoshapes in this format).

With the above, and using select and select-one with appearance="geoshape", your project could perhaps be reduced to simply creating a new enketo-core widget and nothing else (I would then be very interested in a pull request). I may be overlooking something though and you may need to use a handcrafted XPath expression in your form to obtain the id from the selected geoshape.

I wonder if it would be straightforward (and not require changes on the
Formhub side) to load select values from an uploaded GeoJSON file rather
than CSV. This isn't a hard requirement, but would make creating/working
with geometry nicer. Does Formhub server-side validate selected values
against the CSV file? If so, it seems like changes would be needed on the
server to support loading values from GeoJSON.

If external data is required, it would be nice to use a format that can easily be converted to XML (XML itself would be best), in order to be able to use plain XPath (or some custom XPath function) to obtain the required values from it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants